diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-05-05 14:22:38 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-07-15 11:27:30 +0100 |
commit | 34f997c8f7475211920a8d41b6905a6da2462b28 (patch) | |
tree | a3987dae42b7a77dc574e81c65aa9a6e854222a5 /gdb/symfile.h | |
parent | b664df49f3d07941874dce0bd991c48a37cbf409 (diff) | |
download | binutils-34f997c8f7475211920a8d41b6905a6da2462b28.zip binutils-34f997c8f7475211920a8d41b6905a6da2462b28.tar.gz binutils-34f997c8f7475211920a8d41b6905a6da2462b28.tar.bz2 |
gdb: style filenames in separate debug file warnings
After the commit:
commit 6647f05df023b63bbe056e9167e9e234172fa2ca
Date: Tue Jan 24 18:13:38 2023 +0100
gdb: defer warnings when loading separate debug files
It was pointed out[1] that the warnings being deferred and then later
emitted lacked styling. The warnings lacked styling before the above
commit, but it was suggested that the filenames in these warnings
should be styled, and this commit does this.
There were a couple of previous attempts[2][3][4] to solve this
problem, but these all tried to extend the mechanism introduced in the
above commit, the deferred warnings were placed directly into a
std::vector, but now we tried to, when appropriate, style these
warnings. The review feedback that this approach looked too complex.
So instead, this revision adds a new helper class 'deferred_warnings'
which can be used to collect a set of deferred warnings, and then emit
these deferred warnings later, if needed. This helper class hides the
complexity, so at the point the deferred warning is created no extra
logic is required.
The deferred_warnings class will style the deferred warnings only if
gdb_stderr supports styling. GDB's warnings are sent to gdb_stderr,
so this should ensure we only style when expected.
There was also review feedback[5] that all of the warnings should be
bundled into a single string_file, this has not been done. I feel
pretty strongly that separate warnings should be emitted using
separate "warning" calls. If we do end up with multiple warnings in
this case they aren't really related, one will be about looking up
debug via .gnu_debuglink, while the other will be about build-id based
lookup. So I'd really rather keep the warnings separate.
[1] https://inbox.sourceware.org/gdb-patches/87edr9pcku.fsf@tromey.com/
[2] https://inbox.sourceware.org/gdb-patches/20230216195604.2685177-1-ahajkova@redhat.com/
[3] https://inbox.sourceware.org/gdb-patches/20230217123547.2737612-1-ahajkova@redhat.com/
[4] https://inbox.sourceware.org/gdb-patches/20230320145638.1202335-1-ahajkova@redhat.com/
[5] https://inbox.sourceware.org/gdb-patches/87o7nh1g8h.fsf@tromey.com/
Co-Authored-By: Alexandra Hájková <ahajkova@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Diffstat (limited to 'gdb/symfile.h')
-rw-r--r-- | gdb/symfile.h | 9 |
1 files changed, 6 insertions, 3 deletions
diff --git a/gdb/symfile.h b/gdb/symfile.h index 7c800ea..296fee9 100644 --- a/gdb/symfile.h +++ b/gdb/symfile.h @@ -244,11 +244,14 @@ extern void symbol_file_add_separate (const gdb_bfd_ref_ptr &, const char *, /* Find separate debuginfo for OBJFILE (using .gnu_debuglink section). Returns pathname, or an empty string. - Any warnings generated as part of this lookup are added to - WARNINGS_VECTOR, one std::string per warning. */ + Any warnings generated as part of this lookup are added to WARNINGS. If + some other mechanism can be used to lookup the debug information then + the warning will not be shown, however, if GDB fails to find suitable + debug information using any approach, then any warnings will be + printed. */ extern std::string find_separate_debug_file_by_debuglink - (struct objfile *objfile, std::vector<std::string> *warnings_vector); + (struct objfile *objfile, deferred_warnings *warnings); /* Build (allocate and populate) a section_addr_info struct from an existing section table. */ |