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 8F7573858004 for ; Sun, 29 Nov 2020 01:19:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8F7573858004 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 librem (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id B9B0237251CA for ; Sun, 29 Nov 2020 02:19:42 +0100 (CET) Received: by librem (Postfix, from userid 1000) id E110CC08C7; Sun, 29 Nov 2020 02:18:43 +0100 (CET) Date: Sun, 29 Nov 2020 02:18:43 +0100 From: Mark Wielaard To: elfutils-devel@sourceware.org Subject: Re: Buildbot failure in Wildebeest Builder on whole buildset Message-ID: <20201129011843.GA3019@wildebeest.org> References: <20201128041518.0EE4380071B@builder.wildebeest.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, GIT_PATCH_0, 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: Sun, 29 Nov 2020 01:19:51 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Sat, Nov 28, 2020 at 04:12:25PM +0100, Mark Wielaard wrote: > On Sat, 2020-11-28 at 14:41 +0100, Mark Wielaard wrote: > > That is interesting, it only fails on the two 32bit systems. > > The failure is about the specific error message returned. > > > > FAIL: run-dwflsyms.sh > > ===================== > > --- dwflsyms.out 2020-11-28 01:17:44.130295202 +0000 > > +++ - 2020-11-28 01:17:44.140327188 +0000 > > @@ -10,7 +10,7 @@ > > 9: NOTYPE GLOBAL __kernel_sigtramp_rt64 (12) 0xfffb1af0418 > > 10: NOTYPE GLOBAL __kernel_clock_gettime (152) 0xfffb1af0494 > > 11: NOTYPE GLOBAL __kernel_get_syscall_map (44) 0xfffb1af05f4 > > -ld64.so.1: No symbol table found > > +ld64.so.1: Callback returned failure > > 0: NOTYPE LOCAL (0) 0 > > 1: SECTION LOCAL (0) 0x461b0190 > > 2: SECTION LOCAL (0) 0x461b01a4 > > FAIL run-dwflsyms.sh (exit status: 1) > > > > So there is some subtle difference in the behavior of the > > 'segment_report_module: Inline consider_notes() into only caller' > > patch. > > > > I haven't spotted it yet, but I suspect some 'return' from the original > > function got mistranslated as a continue, break or goto out in the > > inlined variant. > > > > The specific testcase that fails is: > > testrun_compare ${abs_builddir}/dwflsyms -e testfile66 --core=testfile66.core > > > > Which is a big endian ppc64 executable and core file. > > The issue can be replicated on x86_64 with: > > $ CXX="g++ -m32" CC="gcc -m32" ~/src/elfutils/configure --enable-maintainer-mode > $ make -j4 > $ make check TESTS=run-dwflsyms.sh Found it. There was a small change to calculate note_vaddr (so it wouldn't clash with the local vaddr) as: const size_t note_vaddr = start + offset; But size_t is only 32bit on the failing systems, which is obviously not enough for analyzing addresses from a 64bit core file. The fix is simply to use GElf_Addr instead. Pushed the attached to fix it. Cheers, Mark --wac7ysb48OaltWcw Content-Type: text/x-diff; charset=iso-8859-1 Content-Disposition: attachment; filename="0001-libdwfl-Use-64bit-GElf_Addr-instead-of-size_t-to-cal.patch" Content-Transfer-Encoding: 8bit >From 609290a61d4f900c65b7e0e273981022a826e4c0 Mon Sep 17 00:00:00 2001 From: Mark Wielaard Date: Sun, 29 Nov 2020 01:57:53 +0100 Subject: [PATCH] libdwfl: Use 64bit GElf_Addr instead of size_t to calculate address. size_t is too small on 32 bit systems to analyze a 64 bit core file. Signed-off-by: Mark Wielaard --- libdwfl/ChangeLog | 5 +++++ libdwfl/dwfl_segment_report_module.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog index a5cffc49..67a4d743 100644 --- a/libdwfl/ChangeLog +++ b/libdwfl/ChangeLog @@ -1,3 +1,8 @@ +2020-11-28 Mark Wielaard + + * dwfl_segment_report_module.c (dwfl_segment_report_module): + Use GElf_Addr to calculate note_vaddr instead of size_t. + 2020-11-26 Timm Bäder * dwfl_segment_report_module.c (dwfl_segment_report_module): diff --git a/libdwfl/dwfl_segment_report_module.c b/libdwfl/dwfl_segment_report_module.c index 8d99e3bb..ee9cfa2e 100644 --- a/libdwfl/dwfl_segment_report_module.c +++ b/libdwfl/dwfl_segment_report_module.c @@ -501,7 +501,7 @@ dwfl_segment_report_module (Dwfl *dwfl, int ndx, const char *name, /* We calculate from the p_offset of the note segment, because we don't yet know the bias for its p_vaddr. */ - const size_t note_vaddr = start + offset; + const GElf_Addr note_vaddr = start + offset; void *data; size_t data_size; if (read_portion (&read_state, &data, &data_size, -- 2.18.4 --wac7ysb48OaltWcw--