Re: Buildbot failure in Wildebeest Builder on whole buildset

2020-11-28 Thread Mark Wielaard
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

2020-11-28 Thread Mark Wielaard
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

2020-11-28 Thread Mark Wielaard
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