aboutsummaryrefslogtreecommitdiff
path: root/gdb/symfile.h
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-05-05 14:22:38 +0100
committerAndrew Burgess <aburgess@redhat.com>2023-07-15 11:27:30 +0100
commit34f997c8f7475211920a8d41b6905a6da2462b28 (patch)
treea3987dae42b7a77dc574e81c65aa9a6e854222a5 /gdb/symfile.h
parentb664df49f3d07941874dce0bd991c48a37cbf409 (diff)
downloadbinutils-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.h9
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. */