This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 3/3] Access deleted files by /dev/PID/mem

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]