From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 62D39397EC21 for ; Thu, 30 Apr 2020 22:07:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 62D39397EC21 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id CCD1C302BB1C; Fri, 1 May 2020 00:07:13 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 8125540007A2; Fri, 1 May 2020 00:07:13 +0200 (CEST) From: Mark Wielaard To: elfutils-devel@sourceware.org Cc: fche@redhat.com, Mark Wielaard Subject: [PATCH] libdwfl: Handle debugaltlink in dwfl_standard_find_debuginfo. Date: Fri, 1 May 2020 00:07:02 +0200 Message-Id: <20200430220702.9794-1-mark@klomp.org> X-Mailer: git-send-email 2.18.2 X-Spam-Status: No, score=-23.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 22:07:16 -0000 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 --- 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 + + * find-debuginfo.c (dwfl_standard_find_debuginfo): When mod->dw + is already set then try fetching debugaltlink. + 2020-04-25 Mark Wielaard * 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