public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: elfutils-devel@sourceware.org
Cc: fche@redhat.com, Mark Wielaard <mark@klomp.org>
Subject: [PATCH] libdwfl: Handle debugaltlink in dwfl_standard_find_debuginfo.
Date: Fri,  1 May 2020 00:07:02 +0200	[thread overview]
Message-ID: <20200430220702.9794-1-mark@klomp.org> (raw)

When we fall back to the debuginfod client then we need to do the
same trick we do for local lookups in dwfl_build_id_find_debuginfo.
If the debug file (dw) is already set, then we must be looking for
the altfile. But we cannot use the actual file/path name given as
hint. We'll have to lookup the alt file "build-id". Because the
debuginfod client only handles build-ids.

Previously we would use the build-id of the main file which meant
the debuginfod client would give us another copy of the debug file,
which would then be set as its own altfile. This caused lots of
confusion...

Signed-off-by: Mark Wielaard <mark@klomp.org>
---
 libdwfl/ChangeLog        |  5 +++++
 libdwfl/find-debuginfo.c | 23 +++++++++++++++++++++--
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index daedaed8..3f9cd665 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-30  Mark Wielaard  <mark@klomp.org>
+
+	* find-debuginfo.c (dwfl_standard_find_debuginfo): When mod->dw
+	is already set then try fetching debugaltlink.
+
 2020-04-25  Mark Wielaard  <mark@klomp.org>
 
 	* gzip.c (open_stream): Return DWFL_E_NOMEM instead of calling
diff --git a/libdwfl/find-debuginfo.c b/libdwfl/find-debuginfo.c
index 2dd11c48..4cfd0b8b 100644
--- a/libdwfl/find-debuginfo.c
+++ b/libdwfl/find-debuginfo.c
@@ -398,8 +398,27 @@ dwfl_standard_find_debuginfo (Dwfl_Module *mod,
       free (canon);
     }
 
-  if (fd < 0 && bits_len > 0)
-    fd = __libdwfl_debuginfod_find_debuginfo (mod->dwfl, bits, bits_len);
+  /* Still nothing? Try if we can use the debuginfod client.
+     But note that we might be looking for the alt file.
+     We use the same trick as dwfl_build_id_find_debuginfo.
+     If the debug file (dw) is already set, then we must be
+     looking for the altfile. But we cannot use the actual
+     file/path name given as hint. We'll have to lookup the
+     alt file "build-id". Because the debuginfod client only
+     handles build-ids.  */
+  if (fd < 0)
+    {
+      if (mod->dw != NULL)
+	{
+	  const char *altname;
+	  bits_len = INTUSE(dwelf_dwarf_gnu_debugaltlink) (mod->dw, &altname,
+							   (const void **)
+							   &bits);
+	}
+
+      if (bits_len > 0)
+	fd = __libdwfl_debuginfod_find_debuginfo (mod->dwfl, bits, bits_len);
+    }
 
   return fd;
 }
-- 
2.18.2


             reply	other threads:[~2020-04-30 22:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 22:07 Mark Wielaard [this message]
2020-05-06 11:07 ` Mark Wielaard

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=20200430220702.9794-1-mark@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=fche@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).