From: Simon Marchi <simon.marchi@polymtl.ca>
To: John Baldwin <jhb@freebsd.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 1/2] Look for separate debug files in debug directories under a sysroot.
Date: Sat, 26 Jan 2019 17:12:00 -0000 [thread overview]
Message-ID: <96b4fb01-d703-ad1b-5ea5-d7e5366f5f6b@polymtl.ca> (raw)
In-Reply-To: <14397d0976052cba984ffbe8e0a54e37@polymtl.ca>
On 2019-01-26 12:16 a.m., Simon Marchi wrote:
> As discussed on IRC, we should probably add the same behavior for
> build-id-based separate debug files.
I gave a shot to this, here's what I have:
From 377ef615ad6e2c57966c8853c61cbce95ea6c2b3 Mon Sep 17 00:00:00 2001
From: Simon Marchi <simon.marchi@polymtl.ca>
Date: Sat, 26 Jan 2019 11:34:45 -0500
Subject: [PATCH] Look for build-id-based separate debug files under the
sysroot
When looking for a separate debug file that matches a given build-id,
GDB only looks in the host's debug dir (typically /usr/lib/debug). This
patch makes it look in the sysroot as well. This is to match the
behavior of GDB when using debuglink-based separate debug files.
In the following example, my sysroot is "/tmp/sysroot" and I am trying
to load symbols for
/tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is
the current behavior:
(gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so...
Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path
<snip>
(No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so)
With this patch:
(gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so...
Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path
Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes!
Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug...
In the original code, there is a suspicious "abfd.release ()" in
build_id_to_debug_bfd, that I don't understand. If a file with the
right name exists but its build-id note doesn't match, we release (leak)
our reference, meaning the file will stay open? I removed it in the new
code, so that the reference is dropped if we end up not using that file.
I tested briefly by corrupting a separate debug file to trigger this
code, nothing exploded.
gdb/ChangeLog:
* build-id.c (build_id_to_debug_bfd_1): New function.
(build_id_to_debug_bfd): Look for separate debug file in
sysroot.
---
gdb/build-id.c | 115 +++++++++++++++++++++++++++++++------------------
1 file changed, 72 insertions(+), 43 deletions(-)
diff --git a/gdb/build-id.c b/gdb/build-id.c
index e0c35579cd4a..27f29cd04423 100644
--- a/gdb/build-id.c
+++ b/gdb/build-id.c
@@ -65,13 +65,63 @@ build_id_verify (bfd *abfd, size_t check_len, const bfd_byte *check)
return retval;
}
+/* Helper for build_id_to_debug_bfd. LINK is a path to a potential
+ build-id-based separate debug file, potentially a symlink to the real file.
+ If the file exists and matches BUILD_ID, return a BFD reference to it. */
+
+static gdb_bfd_ref_ptr
+build_id_to_debug_bfd_1 (const std::string &link, size_t build_id_len,
+ const bfd_byte *build_id)
+{
+ if (separate_debug_file_debug)
+ {
+ printf_unfiltered (_(" Trying %s..."), link.c_str ());
+ gdb_flush (gdb_stdout);
+ }
+
+ /* lrealpath() is expensive even for the usually non-existent files. */
+ gdb::unique_xmalloc_ptr<char> filename;
+ if (access (link.c_str (), F_OK) == 0)
+ filename.reset (lrealpath (link.c_str ()));
+
+ if (filename == NULL)
+ {
+ if (separate_debug_file_debug)
+ printf_unfiltered (_(" no, unable to compute real path\n"));
+
+ return {};
+ }
+
+ /* We expect to be silent on the non-existing files. */
+ gdb_bfd_ref_ptr debug_bfd = gdb_bfd_open (filename.get (), gnutarget, -1);
+
+ if (debug_bfd == NULL)
+ {
+ if (separate_debug_file_debug)
+ printf_unfiltered (_(" no, unable to open.\n"));
+
+ return {};
+ }
+
+ if (!build_id_verify (debug_bfd.get(), build_id_len, build_id))
+ {
+ if (separate_debug_file_debug)
+ printf_unfiltered (_(" no, build-id does not match.\n"));
+
+ return {};
+ }
+
+ if (separate_debug_file_debug)
+ printf_unfiltered (_(" yes!\n"));
+
+ return debug_bfd;
+}
+
/* See build-id.h. */
gdb_bfd_ref_ptr
build_id_to_debug_bfd (size_t build_id_len, const bfd_byte *build_id)
{
- gdb_bfd_ref_ptr abfd;
-
/* Keep backward compatibility so that DEBUG_FILE_DIRECTORY being "" will
cause "/.build-id/..." lookups. */
@@ -83,6 +133,10 @@ build_id_to_debug_bfd (size_t build_id_len, const bfd_byte *build_id)
const gdb_byte *data = build_id;
size_t size = build_id_len;
+ /* Compute where the file named after the build-id would be.
+
+ If debugdir is "/usr/lib/debug" and the build-id is abcdef, this will
+ give "/usr/lib/debug/.build-id/ab/cdef.debug". */
std::string link = debugdir.get ();
link += "/.build-id/";
@@ -97,53 +151,28 @@ build_id_to_debug_bfd (size_t build_id_len, const bfd_byte *build_id)
link += ".debug";
- if (separate_debug_file_debug)
- {
- printf_unfiltered (_(" Trying %s..."), link.c_str ());
- gdb_flush (gdb_stdout);
- }
+ gdb_bfd_ref_ptr debug_bfd
+ = build_id_to_debug_bfd_1 (link, build_id_len, build_id);
+ if (debug_bfd != NULL)
+ return debug_bfd;
- /* lrealpath() is expensive even for the usually non-existent files. */
- gdb::unique_xmalloc_ptr<char> filename;
- if (access (link.c_str (), F_OK) == 0)
- filename.reset (lrealpath (link.c_str ()));
+ /* Try to look under the sysroot as well. If the sysroot is
+ "/the/sysroot", it will give
+ "/the/sysroot/usr/lib/debug/.build-id/ab/cdef.debug".
- if (filename == NULL)
+ Don't do it if the sysroot is the target system ("target:"). It
+ could work in theory, but the lrealpath in build_id_to_debug_bfd_1
+ only works with local paths. */
+ if (strcmp (gdb_sysroot, TARGET_SYSROOT_PREFIX) != 0)
{
- if (separate_debug_file_debug)
- printf_unfiltered (_(" no, unable to compute real path\n"));
-
- continue;
+ link = gdb_sysroot + link;
+ debug_bfd = build_id_to_debug_bfd_1 (link, build_id_len, build_id);
+ if (debug_bfd != NULL)
+ return debug_bfd;
}
-
- /* We expect to be silent on the non-existing files. */
- abfd = gdb_bfd_open (filename.get (), gnutarget, -1);
-
- if (abfd == NULL)
- {
- if (separate_debug_file_debug)
- printf_unfiltered (_(" no, unable to open.\n"));
-
- continue;
- }
-
- if (build_id_verify (abfd.get(), build_id_len, build_id))
- {
- if (separate_debug_file_debug)
- printf_unfiltered (_(" yes!\n"));
-
- break;
- }
- else
- {
- if (separate_debug_file_debug)
- printf_unfiltered (_(" no, build-id does not match.\n"));
- }
-
- abfd.release ();
}
- return abfd;
+ return {};
}
/* See build-id.h. */
--
2.20.1
next prev parent reply other threads:[~2019-01-26 17:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 1:04 [PATCH 0/2] Some fixes for debug files and sysroots John Baldwin
2019-01-23 1:04 ` [PATCH 1/2] Look for separate debug files in debug directories under a sysroot John Baldwin
2019-01-26 5:17 ` Simon Marchi
2019-01-26 17:12 ` Simon Marchi [this message]
2019-01-28 18:53 ` John Baldwin
2019-02-22 20:51 ` Simon Marchi
2019-01-23 1:04 ` [PATCH 2/2] Trim trailing directory separators from new sysroots John Baldwin
2019-01-26 19:10 ` Simon Marchi
2019-01-28 20:41 ` John Baldwin
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=96b4fb01-d703-ad1b-5ea5-d7e5366f5f6b@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
--cc=jhb@freebsd.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: link
Be 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