On Sat, 2014-02-22 at 22:09 +0100, Jan Kratochvil wrote:
the core. The testcase mostly comes from the former patch.
> 2014-02-22 Jan Kratochvil <jan.kratochvil(a)redhat.com>
> Access deleted files by /dev/PID/mem.
> * dwfl_module.c (dwfl_report_module_pid): New function.
> * dwfl_module_getdwarf.c (open_elf): Call __libdw_open_file_at_offset.
> * libdwfl.h (dwfl_report_module_pid): New declaration.
> * libdwflP.h (struct Dwfl_Module): New field pid.
> (INTDECL (dwfl_report_module_pid)): New.
> * linux-proc-maps.c (proc_maps_report): New variable first_high.
> (proc_maps_report) (report): Possibly call dwfl_report_module_pid.
A few high-level questions/suggestions to help me better understand why
this works as it does.
- 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.
- 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
- 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
Do note that I had trouble getting elf_from_remote_memory to work
correctly for anything besides the vdso. If I remember correctly there
were some alignment requirements that didn't work out in some cases
while scanning the PT_LOAD segments. I'll look for my hacks to see if
there is anything useful.