On Wed, 2014-02-26 at 18:27 +0100, Jan Kratochvil wrote: > 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.
I figured out what was going on and posted some patches to fix some issues with elf_from_remote_memory that hopefully help understand things better. > 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. I didn't know BFD does something similar. Is that just for ELF or does BFD handle multiple formats from memory? > elf_from_remote_memory seems to share this problem. Yes, it doesn't know for sure how and where the dynamic linker will have placed the ELF loadable segments. But given an ELF image load address and the phdrs it will be possible to know which file ranges have been mapped to which segments using the phdr PT_LOADs. It does need match how the dynamic loader handles the PT_LOADs. > 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. Combining elf_from_remote_memory with the /proc/PID/maps addresses would certainly make this more robust (and it would probably have caught the alignment issue quicker). But I think using elf_from_remote_memory does (now) also give the valid ranges on its own. Lets see how to combine the approaches most effectively. I'll try and cleanup my patch to linux-proc-maps.c to make it possible to use elf_from_remote_memory for "(deleted)" files to make it easier to test things out. Cheers, Mark
