gdb/corefile: don't pretend unavailable sections are readable

When GDB opens a core file the bfd library processes the core file and
creates sections within the bfd object to represent each of the
segments within the core file.

GDB then creates two target_section lists, m_core_section_table and
m_core_file_mappings, these, along with m_core_unavailable_mappings,
are used by GDB to implement core_target::xfer_partial; this is the
function used when GDB tries to read memory from a core file inferior.

The m_core_section_table list represents sections within the core file
itself.  The sections in this list can be split into two groups based
on whether the section has the SEC_HAS_CONTENTS flag set or not.

Sections (from the core file) that have the SEC_HAS_CONTENTS flag had
their contents copied into the core file when the core file was
created.  These correspond to writable sections within the original
inferior (the inferior for which the core file was created).

Sections (from the core file) that do not have the SEC_HAS_CONTENTS
flag will not have had their contents copied into the core file when
it was created.  These sections correspond to read-only sections
mapped from a file (possibly the initial executable, or possibly some
other file) in the original inferior.  The expectation is that the
contents of these sections can still be found by looking in the file
that was originally mapped.

The m_core_file_mappings list is created when GDB parses the mapped
file list in the core file.  Every mapped region will be covered by
entries in the m_core_section_table list (see above), but for
read-only mappings the entry in m_core_section_table will not have the
SEC_HAS_CONTENTS flag set.  As GDB parses the mapped file list, if the
file that was originally mapped can be found, then GDB creates an
entry in the m_core_file_mappings list which represents the region
of the file that was mapped into the original inferior.

However, GDB only creates entries in m_core_file_mappings if it is
able to find the correct on-disk file to open.  If the file can't be
found then an entry is added to m_core_unavailable_mappings instead.

If is the handling m_core_unavailable_mappings which I think is
currently not completely correct.

When a read lands within an m_core_unavailable_mappings region we
currently forward the read to the exec file stratum.  The reason for
this is this: when GDB read the mapped file list, if the executable
file could not be found at the expected path then mappings within the
executable will end up in the m_core_unavailable_mappings list.

However, the user might provide the executable to GDB from a different
location.  If this happens then forwarding the read to the exec file
stratum might give a result.

But, if the exec file stratum does not resolve the access then
currently we continue through ::xfer_partial, the next step of which
is to handle m_core_section_table entries that don't have the
SEC_HAS_CONTENTS flag set.  Every m_core_unavailable_mappings entry
will naturally have an m_core_section_table without the
SEC_HAS_CONTENTS flag set, and so we treat the unavailable mapping as
zero initialised memory and return all zeros.

It is this fall through behaviour that I think is wrong.  If a read
falls in an unavailable region, and the exec file stratum cannot help,
then I think the access should fail.

To achieve this goal I have removed the xfer_memory_via_mappings
helper function and moved its content inline into ::xfer_partial.
Now, if an access is within an m_core_unavailable_mappings region, and
the exec file stratum doesn't help, we immediately return with an
error.

The reset of ::xfer_partial is unchanged, I've extended some comments
in the area that I have changed to (I hope) explain better what's
going on.

There's a new test that covers the new functionality, an inferior maps
a file and generates a core file.  We then remove the mapped file,
load the core file and try to read from the mapped region.  The
expectation is that GDB should give an error rather than claiming that
the region is full of zeros.

0 files changed, 0 insertions, 0 deletions