Re: [PATCH] make gcore dump read-only sections not from files

[Roland McGrath <roland at redhat dot com>]

> I guess you mean this?

Right.

>  > Note that this patch makes gcore dump more regions than the Linux
>  > kernel does even with my change to its behavior.  In particular,
>  > read-only mmap'd portions of files are dumped by gcore but not by the
>  > kernel.  This is a real common issue in practice, as your average
>  > GNU/Linux process nowadays has the large locale-archive file mapped
>  > in, and some processes may be mapping huge files in read-only.  An
>  > alternative change would be to change the to_find_memory_regions
>  > callback interface to add a flag argument saying whether the memory
>  > region came from a file.  Then gcore_create_callback could simply test
>  > !write && !anonymous and be wholly consistent with the kernel core
>  > dumping (assuming my change to it), and the infrun.c change is not
>  > required
> 
> Sounds reasonable -- is it portable?  A portable testcase for the
> testsuite would make the change fairly easy to evaluate / approve.

I don't understand what you mean by portable in this context.  Such a
notion as anonymous vs file-backed memory is sensical across systems, so
there's nothing "anti-portable" about adding that concept into the
to_find_memory_regions function interface.  

If you mean, can the information be found and reported on systems of other
Linux, then yes.  That is, to_find_memory_regions is implemented only in
procfs.c and gnu-nat.c, and both of those can glean the flag from the
information they already read.

If you mean, is this choice of which regions of memory to omit from the
core dump consistent with what many kernels write in their core dumps, it's
harder to say but the answer is mostly yes.  I also don't think it matters,
except in that we err on the side of omitting fewer.  Linux before 2.6
omitted all read-only regions, which is what gdb did before any of my
changes.  Linux 2.6 now omits only read-only regions backed by files.  A
quick test on Solaris 9 suggests that this is what it's doing as well.  (I
am the author and maintainer of the GNU/Hurd core writing code, so it will
do whatever I think is best anyway.)


Thanks,
Roland