Re: [PATCH v2 4/5] Provide access to non SEC_HAS_CONTENTS core file sections

[Kevin Buettner <kevinb@redhat.com>]

On Wed, 20 May 2020 17:45:28 +0100
Pedro Alves <palves@redhat.com> wrote:

> So, as discussed at <https://sourceware.org/pipermail/gdb-patches/2020-May/168826.html>,
> I still think that this is an heuristic, and that we're trading one
> bug for another.  It does seem like the bug that we're fixing
> is more important than the one we're introducing, so if there's really
> nothing else in the core file that would distinguish the coremaker_ro
> case from an anonymous mapping that should be read from the core (i.e.,
> read as zeroes), then I suppose this is the best we can do, and the
> patch looks good to me.  I would like to see the commit log and the
> comments slightly adjusted to mention this, though.

On Linux, we're able to do "info proc mappings" when looking at a
corefile.  Linux core files include a .note.linuxcore.file/pid section
which contain the map data that you see when running "info proc
mappings".

It may be possible to use these mappings to provide a more accurate
view of memory contents when working with a core file.  In addition
to file backed data that we already know about from the executable and
shared libraries, there may be additional file backed data that can
be found via files listed in the .note section mentioned earlier.  Or,
as I found while investigating that one of those weird F27 mappings,
there may be data from a shared library which can't be found in
what GDB knows about when loading the shared library.  (In that
particular case, the memory region in question contained some
vtable data prior to being remapped - though I'm guessing about
the remapping bit.)

If you think it worth pursuing, I can look at using the core-provided
proc mapping information to provide a more accurate view of memory
when looking at a core dump.

If I do this, is it still worth pushing this v2 series first?  Or should
it wait until I attempt to incorporate info from the .note section?

> Could you remind me again why is it that the core dump includes a
> load segment for coremaker_ro in the first place?  If this is
> read-only data, why did the kernel decide to output a bss-like
> load segment for it?

On F27 and F28, coremaker_ro was placed on a page that also had
read/write data; it got included in with that data when the core file
was written.

On F29 and beyond (due to use of particular bintutils verions/options
which participated in making the executable), coremaker_ro was placed
on a page with only read-only data.  In this case, the core file
didn't include data for that page; it lets the debugger find that data
from the executable.

Kevin