On Tue, 25 Feb 2014 23:56:23 +0100, Mark Wielaard wrote:
- Could we reuse dwfl_pid () instead of adding another pid concept
to
struct Dwfl_Module? Then a user could just use dwfl_linux_proc_attach
which might also help us get into the ptrace attach state if needed
for reading /proc/PID/mem.
OK, I will try that.
- If possible having the detection of whether to use direct file
access
or using a /proc/PID/mem mapping in the dwfl_linux_proc_find_elf
instead of in proc_maps_report would be nice. That way it can be used
more generically as fallback for when direct file access fails for
whatever reason.
OK, I will try that.
- If you look at elf_from_remote_memory (as used to fetch the vdso
if
possible) you'll see that it tries to clean up the headers a bit (like
zeroing out the shdr offset and size if it cannot be found). You might
want to do the same for the mmaped image so that we don't even try to
read the section headers if they aren't there (and possibly read
garbage). It also tries to minimize the used/read memory by scanning
the PT_LOAD segments. But your maximum_size calculation might be
easier.
elf_from_remote_memory was discussed elsewhere, I find /proc/PID/mem better
when it is available.
I could zero out the headers but I find that redundant to existing
maximum_size protection, therefore I will implement it only upon further
request.
Thanks,
Jan