tree 3d345109b6d3b96ec8b05e42e52e688393066fd9
parent 7fa205d2fe280f331ff08de24198229fa864014f
author Andrew Burgess <aburgess@redhat.com> 1741778202 +0000
committer Andrew Burgess <aburgess@redhat.com> 1744410772 +0100

gdb: silence some 'Can't open file' warnings from core file loading

But PR gdb/20126 highlights a case where GDB emits a large number of
warnings like:

  warning: Can't open file /anon_hugepage (deleted) during file-backed mapping note processing
  warning: Can't open file /dev/shm/PostgreSQL.1150234652 during file-backed mapping note processing
  warning: Can't open file /dev/shm/PostgreSQL.535700290 during file-backed mapping note processing
  warning: Can't open file /SYSV604b7d00 (deleted) during file-backed mapping note processing
  ... etc ...

when opening a core file.  This commit aims to avoid at least some of
these warnings.

What we know is that, for at least some of these cases, (e.g. the
'(deleted)' mappings), the content of the mapping will have been
written into the core file itself.  As such, the fact that the file
isn't available ('/SYSV604b7d00' at least is a shared memory mapping),
isn't really relevant, GDB can still provide access to the mapping, by
reading the content from the core file itself.

What I propose is that, when processing the file backed mappings, if
all of the mappings for a file are covered by segments within the core
file itself, then there is no need to warn the user that the file
can't be opened again.  The debug experience should be unchanged, as
GDB would have read from the in-core mapping anyway.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30126