diff options
author | Andrew Burgess <aburgess@redhat.com> | 2025-03-12 11:16:42 +0000 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2025-04-11 23:32:52 +0100 |
commit | 33d5188ab101bf414c9950ba914a128d08166105 (patch) | |
tree | 3d345109b6d3b96ec8b05e42e52e688393066fd9 /gdb/testsuite/gdb.compile/compile-cplus-virtual.exp | |
parent | 7fa205d2fe280f331ff08de24198229fa864014f (diff) | |
download | binutils-33d5188ab101bf414c9950ba914a128d08166105.zip binutils-33d5188ab101bf414c9950ba914a128d08166105.tar.gz binutils-33d5188ab101bf414c9950ba914a128d08166105.tar.bz2 |
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
Diffstat (limited to 'gdb/testsuite/gdb.compile/compile-cplus-virtual.exp')
0 files changed, 0 insertions, 0 deletions