Re: Buildbot failure in Wildebeest Builder on whole buildset
Hi, On Sat, 2020-11-28 at 04:15 +, build...@builder.wildebeest.org wrote: > The Buildbot has detected a failed build on builder whole buildset > while building elfutils. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/4/builds/640 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: debian-i386 > > The Buildbot has detected a failed build on builder > whole buildset while building elfutils. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/15/builds/436 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: debian-armhf 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.out2020-11-28 01:17:44.130295202 + +++ - 2020-11-28 01:17:44.140327188 + @@ -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. Cheers, Mark
Re: Buildbot failure in Wildebeest Builder on whole buildset
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 + > +++ - 2020-11-28 01:17:44.140327188 + > @@ -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: SECTIONLOCAL(0) 0x461b0190 > 2: SECTIONLOCAL(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
Re: Buildbot failure in Wildebeest Builder on whole buildset
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.out2020-11-28 01:17:44.130295202 + > > +++ - 2020-11-28 01:17:44.140327188 + > > @@ -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>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