public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Lancelot SIX <lsix@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdb: ensure has dwarf info before reading DWZ file Date: Wed, 3 Apr 2024 12:52:29 +0000 (GMT) [thread overview] Message-ID: <20240403125229.C49843858401@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e73b04d26504214f52a3b87f51917d26aba8e82c commit e73b04d26504214f52a3b87f51917d26aba8e82c Author: Lancelot SIX <lancelot.six@amd.com> Date: Sat Mar 30 11:01:21 2024 +0000 gdb: ensure has dwarf info before reading DWZ file I recent change (e9b738dfbdc "Avoid race when reading dwz file") moved the call to dwarf2_read_dwz_file from dwarf2_initialize_objfile to dwarf2_has_info. Before that patch, dwarf2_initialize_objfile was only called when dwarf2_has_info returned true, and since that patch it is always called. When reading a file that has no debug info (.debug_info/.debug_abbrev sections), but has a .gnu_debugaltlink section, GDB’s behavior is different. I can observe this when loading /lib/x86_64-linux-gnu/libtinfo.so on Ubuntu 22.04 (or while debugging any program dynamically loading this library). Before e9b738dfbdc, we had: $ ./gdb/gdb -data-directory ./gdb/data-directory -q /lib/x86_64-linux-gnu/libtinfo.so Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so... (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so) (gdb) while after we have: $ ./gdb/gdb -data-directory ./gdb/data-directory -q /lib/x86_64-linux-gnu/libtinfo.so Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so... warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/libtinfo.so.6.3 (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so) (gdb) This patch restores the previous behavior of only trying to load the DWZ file for objfiles when the main part of the debuginfo is present (i.e. when dwarf2_has_info returns true). We still make sure that dwarf2_read_dwz_file is called at most once per objfile. A consequence of this change is that the per_bfd->dwz_file optional object can now remain empty (instead of containing a nullptr), so also this patch also adjusts dwarf2_get_dwz_file to account for this possibility. This effectively reverts the changes to dwarf2_get_dwz_file done by e9b738dfbdc. Regression tested on x86_64-linux-gnu Ubuntu 22.04. Approved-By: Tom Tromey <tom@tromey.com> Diff: --- gdb/dwarf2/dwz.c | 13 +++++++++---- gdb/dwarf2/read.c | 36 +++++++++++++++++++----------------- 2 files changed, 28 insertions(+), 21 deletions(-) diff --git a/gdb/dwarf2/dwz.c b/gdb/dwarf2/dwz.c index 1eb4816fb47..c7cdba24076 100644 --- a/gdb/dwarf2/dwz.c +++ b/gdb/dwarf2/dwz.c @@ -282,9 +282,14 @@ dwarf2_read_dwz_file (dwarf2_per_objfile *per_objfile) struct dwz_file * dwarf2_get_dwz_file (dwarf2_per_bfd *per_bfd, bool require) { - gdb_assert (per_bfd->dwz_file.has_value ()); - dwz_file *result = per_bfd->dwz_file->get (); - if (require && result == nullptr) - error (_("could not read '.gnu_debugaltlink' section")); + gdb_assert (!require || per_bfd->dwz_file.has_value ()); + + dwz_file *result = nullptr; + if (per_bfd->dwz_file.has_value ()) + { + result = per_bfd->dwz_file->get (); + if (require && result == nullptr) + error (_("could not read '.gnu_debugaltlink' section")); + } return result; } diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 31313bc88b3..9e37011ddf0 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -1362,11 +1362,11 @@ dwarf2_has_info (struct objfile *objfile, return false; dwarf2_per_objfile *per_objfile = get_dwarf2_per_objfile (objfile); + bool just_created = false; if (per_objfile == NULL) { dwarf2_per_bfd *per_bfd; - bool just_created = false; /* We can share a "dwarf2_per_bfd" with other objfiles if the BFD doesn't require relocations. @@ -1398,27 +1398,29 @@ dwarf2_has_info (struct objfile *objfile, } per_objfile = dwarf2_objfile_data_key.emplace (objfile, objfile, per_bfd); + } + + const bool has_info = (!per_objfile->per_bfd->info.is_virtual + && per_objfile->per_bfd->info.s.section != nullptr + && !per_objfile->per_bfd->abbrev.is_virtual + && per_objfile->per_bfd->abbrev.s.section != nullptr); - if (just_created) + if (just_created && has_info) + { + /* Try to fetch any potential dwz file early, while still on + the main thread. Also, be sure to do it just once per + BFD, to avoid races. */ + try { - /* Try to fetch any potential dwz file early, while still on - the main thread. Also, be sure to do it just once per - BFD, to avoid races. */ - try - { - dwarf2_read_dwz_file (per_objfile); - } - catch (const gdb_exception_error &err) - { - warning (_("%s"), err.what ()); - } + dwarf2_read_dwz_file (per_objfile); + } + catch (const gdb_exception_error &err) + { + warning (_("%s"), err.what ()); } } - return (!per_objfile->per_bfd->info.is_virtual - && per_objfile->per_bfd->info.s.section != NULL - && !per_objfile->per_bfd->abbrev.is_virtual - && per_objfile->per_bfd->abbrev.s.section != NULL); + return has_info; } /* See declaration. */
reply other threads:[~2024-04-03 12:52 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=20240403125229.C49843858401@sourceware.org \ --to=lsix@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).