On Wed, 26 Feb 2014 17:42:26 +0100, Mark Wielaard wrote:
I'll try and understand what I was trying to do,
clean it up and post it, if it looks useful/sane.
OK, I think we can talk about it even in abstract.
The primary problem of bfd_from_remote_memory (bfd/elfcode.h) always IMO was
that it does not know the valid range of memory addresses belonging to the ELF
file. elf_from_remote_memory seems to share this problem.
These functions (used for vDSO) have to work on arbitrary target, including
core files or remote gdbserver. In these cases one does not have such
valuable resource as /proc/PID/maps (*). For the elfutils case of deleted
file of a live PID we always have the /proc/PID/maps resource.
(*) Nowadays one already has NT_FILE for core files and
target_fileio_read_stralloc("/proc/PID/maps") for gdbserver.
But existing bfd_from_remote_memory is from time where those were not yet
available and so bfd_from_remote_memory does not try to use these.
While the backtrace of deleted file would be useful even for core files the
default dumping omits the readonly (=.eh_frame) segments so it is not usable
anyway. (**)
(**) I think this default omitting of code segments only causes more harm than
good, if the core file is big it is always due to r/w data segments and
not due to the code. But so far nobody has changed the default yet.
Maybe because core file analysis tools would then be too easy to write.
So while I did not remember elf_from_remote_memory could be applicable in this
case in the end I still find the current solution of replacing
elf_from_remote_memory logic by reading ELF boundaries from /proc/PID/maps
instead as more safe/reliable.
Sure going to address other specific comments from your review.
Thanks,
Jan