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
