aboutsummaryrefslogtreecommitdiff
path: root/bfd
diff options
context:
space:
mode:
authorLancelot SIX <lancelot.six@amd.com>2023-05-31 12:23:05 +0100
committerLancelot SIX <lancelot.six@amd.com>2023-06-08 14:18:09 +0100
commit0ad504dd4645153fc7c6e8e6a5979b0f79830341 (patch)
tree65ff2509070856496a1f907d8649ee2d778d9d46 /bfd
parent9b3a1001c8405965b3142d7361c13049714e543f (diff)
downloadgdb-0ad504dd4645153fc7c6e8e6a5979b0f79830341.zip
gdb-0ad504dd4645153fc7c6e8e6a5979b0f79830341.tar.gz
gdb-0ad504dd4645153fc7c6e8e6a5979b0f79830341.tar.bz2
gdb/corelow.c: avoid repeated warnings in build_file_mappings
When GDB opens a coredump it tries to locate and then open all files which were mapped in the process. If a file is found but cannot be opened with BFD (bfd_open / bfd_check_format fails), then a warning is printed to the user. If the same file was mapped multiple times in the process's address space, the warning is printed once for each time the file was mapped. I find this un-necessarily noisy. This patch makes it so the warning message is printed only once per file. There was a comment in the code assuming that if the file was found on the system, opening it (bfd_open + bfd_check_format) should always succeed. A recent change in BFD (014a602b86f "Don't optimise bfd_seek to same position") showed that this assumption is not valid. For example, it is possible to have a core dump of a process which had mmaped an IO page from a DRI render node (/dev/dri/runderD$NUM). In such case the core dump does contain the information that portions of this special file were mapped in the host process, but trying to seek to position 0 will fail, making bfd_check_format fail. This patch removes this comment. Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
Diffstat (limited to 'bfd')
0 files changed, 0 insertions, 0 deletions