public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] Suppress printing of superfluous BFD error messages Date: Fri, 16 Sep 2022 23:31:23 +0000 (GMT) [thread overview] Message-ID: <20220916233123.69B4B385354F@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=84e605558eb8a3aeec636e32de5d3573242d462e commit 84e605558eb8a3aeec636e32de5d3573242d462e Author: Kevin Buettner <kevinb@redhat.com> Date: Fri Sep 16 16:13:29 2022 -0700 Suppress printing of superfluous BFD error messages This commit adds a hook to the BFD error handler for suppressing identical messages which have been output once already. It's motivated by this Fedora bug... https://bugzilla.redhat.com/show_bug.cgi?id=2083315 ...in which over 900,000 BFD error messages are output when attaching to firefox. From the bug report, the messages all say: BFD: /usr/lib/debug/usr/lib64/firefox/libxul.so-100.0-2.fc35.x86_64.debug: attempt to load strings from a non-string section (number 38) Since there's no (additional) context which might assist the user in determining what's wrong, there's really no point in outputting more than one message. Of course, if BFD should output some other/different message, it should be output too, but all future messages identical to those already output should be suppressed. For the firefox problem, it turned out that there were only 37 sections, but something was referring to section #38. I haven't investigated further to find out how this came to be. Despite this problem, useful debugging might still be done, especially if the user doesn't care about debugging the problematic library. If it turns out that knowing the quantity of messages might be useful, I've implemented the suppression mechanism by keeping a count of each identical message. A new GDB command, perhaps a 'maintenance' command, could be added to print out each message along with the count. I haven't implemented this though because I'm not convinced of its utility. Also, the BFD message printer has support for BFD- specific format specifiers. The BFD message strings that GDB stores in its map are sufficient for distinguishing messages from each other, but are not identical to those output by BFD's default error handler. So, that problem would need to be solved too. Diff: --- gdb/gdb_bfd.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/gdb/gdb_bfd.c b/gdb/gdb_bfd.c index 6c03ae5ef05..6299148d419 100644 --- a/gdb/gdb_bfd.c +++ b/gdb/gdb_bfd.c @@ -33,6 +33,7 @@ #include "gdb/fileio.h" #include "inferior.h" #include "cli/cli-style.h" +#include <unordered_map> /* An object of this type is stored in the section's user data when mapping a section. */ @@ -1125,6 +1126,69 @@ maintenance_info_bfds (const char *arg, int from_tty) htab_traverse (all_bfds, print_one_bfd, uiout); } +/* BFD related per-inferior data. */ + +struct bfd_inferior_data +{ + std::unordered_map<std::string, unsigned long> bfd_error_string_counts; +}; + +/* Per-inferior data key. */ + +static const registry<inferior>::key<bfd_inferior_data> bfd_inferior_data_key; + +/* Fetch per-inferior BFD data. It always returns a valid pointer to + a bfd_inferior_data struct. */ + +static struct bfd_inferior_data * +get_bfd_inferior_data (struct inferior *inf) +{ + struct bfd_inferior_data *data; + + data = bfd_inferior_data_key.get (inf); + if (data == nullptr) + data = bfd_inferior_data_key.emplace (inf); + + return data; +} + +/* Increment the BFD error count for STR and return the updated + count. */ + +static unsigned long +increment_bfd_error_count (std::string str) +{ + struct bfd_inferior_data *bid = get_bfd_inferior_data (current_inferior ()); + + auto &map = bid->bfd_error_string_counts; + return ++map[std::move (str)]; +} + +static bfd_error_handler_type default_bfd_error_handler; + +/* Define a BFD error handler which will suppress the printing of + messages which have been printed once already. This is done on a + per-inferior basis. */ + +static void +gdb_bfd_error_handler (const char *fmt, va_list ap) +{ + va_list ap_copy; + + va_copy(ap_copy, ap); + const std::string str = string_vprintf (fmt, ap_copy); + va_end (ap_copy); + + if (increment_bfd_error_count (std::move (str)) > 1) + return; + + /* We must call the BFD mechanism for printing format strings since + it supports additional format specifiers that GDB's vwarning() doesn't + recognize. It also outputs additional text, i.e. "BFD: ", which + makes it clear that it's a BFD warning/error. */ + (*default_bfd_error_handler) (fmt, ap); +} + void _initialize_gdb_bfd (); void _initialize_gdb_bfd () @@ -1157,4 +1221,7 @@ When non-zero, bfd cache specific debugging is enabled."), NULL, &show_bfd_cache_debug, &setdebuglist, &showdebuglist); + + /* Hook the BFD error/warning handler to limit amount of output. */ + default_bfd_error_handler = bfd_set_error_handler (gdb_bfd_error_handler); }
reply other threads:[~2022-09-16 23:31 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220916233123.69B4B385354F@sourceware.org \ --to=kevinb@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).