[Bug tools/30072] New: FAIL: run-addr2line-C-test.sh
https://sourceware.org/bugzilla/show_bug.cgi?id=30072 Bug ID: 30072 Summary: FAIL: run-addr2line-C-test.sh Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: tools Assignee: unassigned at sourceware dot org Reporter: mliska at suse dot cz CC: elfutils-devel at sourceware dot org, mark at klomp dot org Target Milestone: --- Created attachment 14650 --> https://sourceware.org/bugzilla/attachment.cgi?id=14650&action=edit Build log The test is pretty new and fails with: [ 30s] FAIL: run-addr2line-C-test.sh [ 30s] = [ 30s] [ 30s] --- addr2line.out 2023-02-03 08:59:30.572855287 + [ 30s] +++ - 2023-02-03 08:59:30.576315349 + [ 30s] @@ -8,12 +8,12 @@ [ 30s] (inlined by) baz at /tmp/x.cpp:20 [ 30s] 0x05e0: foobar at /tmp/x.cpp:5 [ 30s] (inlined by) bar at /tmp/x.cpp:15 [ 30s] - (inlined by) _Z3foov at /tmp/x.cpp:25 [ 30s] + (inlined by) foo() at /tmp/x.cpp:25 [ 30s] 0x05e1: fubar at /tmp/x.cpp:10 [ 30s] (inlined by) baz at /tmp/x.cpp:20 [ 30s] - (inlined by) _Z3foov at /tmp/x.cpp:26 [ 30s] -0x05f0: _Z2fuv at /tmp/x.cpp:31 [ 30s] + (inlined by) foo() at /tmp/x.cpp:26 [ 30s] +0x05f0: fu() at /tmp/x.cpp:31 [ 30s] 0x05f1: fubar at /tmp/x.cpp:10 [ 30s] - (inlined by) _Z2fuv at /tmp/x.cpp:32 [ 30s] + (inlined by) fu() at /tmp/x.cpp:32 [ 30s] 0x05f2: foobar at /tmp/x.cpp:5 [ 30s] - (inlined by) _Z2fuv at /tmp/x.cpp:33 [ 30s] + (inlined by) fu() at /tmp/x.cpp:33 [ 30s] FAIL run-addr2line-C-test.sh (exit status: 1) [ 30s] [ 30s] FAIL: run-addr2line-i-test.sh [ 30s] = [ 30s] [ 30s] --- addr2line.out 2023-02-03 08:59:30.612856288 + [ 30s] +++ - 2023-02-03 08:59:30.615130217 + [ 30s] @@ -1,6 +1,6 @@ [ 30s] -_Z6foobari at /tmp/x.cpp:4:14 [ 30s] - (inlined by) _Z3fooi at /tmp/x.cpp:22:16 [ 30s] - (inlined by) _Z2fui at /tmp/x.cpp:27:13 [ 30s] -_Z5fubari at /tmp/x.cpp:10:14 [ 30s] - (inlined by) _Z3bari at /tmp/x.cpp:16:15 [ 30s] - (inlined by) _Z2fui at /tmp/x.cpp:27:24 [ 30s] +foobar(int) at /tmp/x.cpp:4:14 [ 30s] + (inlined by) foo(int) at /tmp/x.cpp:22:16 [ 30s] + (inlined by) fu(int) at /tmp/x.cpp:27:13 [ 30s] +fubar(int) at /tmp/x.cpp:10:14 [ 30s] + (inlined by) bar(int) at /tmp/x.cpp:16:15 [ 30s] + (inlined by) fu(int) at /tmp/x.cpp:27:24 [ 30s] FAIL run-addr2line-i-test.sh (exit status: 1) So somehow the output is demangled, but the test does not expected it. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] addr2line: -C should not try to handle optional (ignored) argument
On 1/30/23 22:04, Mark Wielaard wrote: > Hi, > > On Mon, Jan 23, 2023 at 10:11:28AM +0100, Mark Wielaard wrote: >> The --demangle option takes an option (ignored) argument. Since -C >> is the short option of --demangle it also takes that optional >> argument. But that means that something like -Cfi is like -C got >> fi as argument, while the user expects -Cfi to be like -C -f -i. >> >> Separate the --demangle and -C options. --demangle still takes >> an optional (ignored) argument, but -C doesn't take any arguments >> so -Cfi acts the same as -fiC. >> >> Also fix --target, -b, so that it is properly ignored (and not >> accidentially enables demangling). > > Pushed. > > Cheers, > > Mark Hi. It caused https://sourceware.org/bugzilla/show_bug.cgi?id=30072 for me. Can you please take a look? Thanks, Martin
[Bug tools/30072] FAIL: run-addr2line-C-test.sh
https://sourceware.org/bugzilla/show_bug.cgi?id=30072 --- Comment #1 from Mark Wielaard --- (In reply to Martin Liska from comment #0) > Created attachment 14650 [details] > Build log > > The test is pretty new and fails with: > > [ 30s] FAIL: run-addr2line-C-test.sh > [ 30s] = > [ 30s] > [ 30s] --- addr2line.out2023-02-03 08:59:30.572855287 + > [ 30s] +++ -2023-02-03 08:59:30.576315349 + > [ 30s] @@ -8,12 +8,12 @@ > [ 30s] (inlined by) baz at /tmp/x.cpp:20 > [ 30s] 0x05e0: foobar at /tmp/x.cpp:5 > [ 30s] (inlined by) bar at /tmp/x.cpp:15 > [ 30s] - (inlined by) _Z3foov at /tmp/x.cpp:25 > [ 30s] + (inlined by) foo() at /tmp/x.cpp:25 > [ 30s] 0x05e1: fubar at /tmp/x.cpp:10 > [ 30s] (inlined by) baz at /tmp/x.cpp:20 > [ 30s] - (inlined by) _Z3foov at /tmp/x.cpp:26 > [ 30s] -0x05f0: _Z2fuv at /tmp/x.cpp:31 > [ 30s] + (inlined by) foo() at /tmp/x.cpp:26 > [ 30s] +0x05f0: fu() at /tmp/x.cpp:31 > [ 30s] 0x05f1: fubar at /tmp/x.cpp:10 > [ 30s] - (inlined by) _Z2fuv at /tmp/x.cpp:32 > [ 30s] + (inlined by) fu() at /tmp/x.cpp:32 > [ 30s] 0x05f2: foobar at /tmp/x.cpp:5 > [ 30s] - (inlined by) _Z2fuv at /tmp/x.cpp:33 > [ 30s] + (inlined by) fu() at /tmp/x.cpp:33 > [ 30s] FAIL run-addr2line-C-test.sh (exit status: 1) > [ 30s] > [ 30s] FAIL: run-addr2line-i-test.sh > [ 30s] = > [ 30s] > [ 30s] --- addr2line.out2023-02-03 08:59:30.612856288 + > [ 30s] +++ -2023-02-03 08:59:30.615130217 + > [ 30s] @@ -1,6 +1,6 @@ > [ 30s] -_Z6foobari at /tmp/x.cpp:4:14 > [ 30s] - (inlined by) _Z3fooi at /tmp/x.cpp:22:16 > [ 30s] - (inlined by) _Z2fui at /tmp/x.cpp:27:13 > [ 30s] -_Z5fubari at /tmp/x.cpp:10:14 > [ 30s] - (inlined by) _Z3bari at /tmp/x.cpp:16:15 > [ 30s] - (inlined by) _Z2fui at /tmp/x.cpp:27:24 > [ 30s] +foobar(int) at /tmp/x.cpp:4:14 > [ 30s] + (inlined by) foo(int) at /tmp/x.cpp:22:16 > [ 30s] + (inlined by) fu(int) at /tmp/x.cpp:27:13 > [ 30s] +fubar(int) at /tmp/x.cpp:10:14 > [ 30s] + (inlined by) bar(int) at /tmp/x.cpp:16:15 > [ 30s] + (inlined by) fu(int) at /tmp/x.cpp:27:24 > [ 30s] FAIL run-addr2line-i-test.sh (exit status: 1) > > So somehow the output is demangled, but the test does not expected it. It looks like the other way around (but the test-suite.log is confusing). Could you check whether configure detected DEMANGLE support? libstdc++ demangle support : yes If not, then the fix would be: diff --git a/tests/run-addr2line-C-test.sh b/tests/run-addr2line-C-test.sh index 8c63d78d..1780157d 100755 --- a/tests/run-addr2line-C-test.sh +++ b/tests/run-addr2line-C-test.sh @@ -18,6 +18,11 @@ . $srcdir/test-subr.sh +if test -n "$ELFUTILS_DISABLE_DEMANGLE"; then + echo "demangler unsupported" + exit 77 +fi + # See run-addr2line-i-test.sh testfiles testfile-inlines -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/30072] FAIL: run-addr2line-C-test.sh
https://sourceware.org/bugzilla/show_bug.cgi?id=30072 --- Comment #2 from Martin Liska --- > It looks like the other way around (but the test-suite.log is confusing). > Could you check whether configure detected DEMANGLE support? > > libstdc++ demangle support : yes Yes, I really miss it: configure:8679: checking for __cxa_demangle in -lstdc++ configure:8702: gcc -o conftest -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -Werror=date-time -g -flto=auto -ffat-lto-objects conftest.c -lstdc++ >&5 /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: cannot find -lstdc++: No such file or directory collect2: error: ld returned 1 exit status configure:8702: $? = 1 configure: failed program was: Oh, apparently my spec file has not BuildRequires of the gcc-c++ package. Adding that, all is green. > > If not, then the fix would be: > > diff --git a/tests/run-addr2line-C-test.sh b/tests/run-addr2line-C-test.sh > index 8c63d78d..1780157d 100755 > --- a/tests/run-addr2line-C-test.sh > +++ b/tests/run-addr2line-C-test.sh > @@ -18,6 +18,11 @@ > > . $srcdir/test-subr.sh > > +if test -n "$ELFUTILS_DISABLE_DEMANGLE"; then > + echo "demangler unsupported" > + exit 77 > +fi > + > # See run-addr2line-i-test.sh > testfiles testfile-inlines This would fix it as well.. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/30072] FAIL: run-addr2line-C-test.sh
https://sourceware.org/bugzilla/show_bug.cgi?id=30072 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Mark Wielaard --- commit dd3c621ff36f73cb26d89a2fd5ea384a5b4c Author: Mark Wielaard Date: Fri Feb 3 13:44:17 2023 +0100 tests: Check ELFUTILS_DISABLE_DEMANGLE in run-addr2line-C-test.sh https://sourceware.org/bugzilla/show_bug.cgi?id=30072 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28873] Implement eu-readelf -D
https://sourceware.org/bugzilla/show_bug.cgi?id=28873 Aaron Merey changed: What|Removed |Added CC||amerey at redhat dot com --- Comment #7 from Aaron Merey --- (In reply to Di Chen from comment #5) > Because I use offset difference between SYMTAB and STRTAB to get the symbol > table entry number. > ``` > size_t syments = ((offs[i_strtab] - offs[i_symtab]) / > gelf_fsize(ebl->elf, ELF_T_SYM, 1, EV_CURRENT)); > ``` > > For a binary with SYMTAB STRTAB having different order, like upside down, or > having other section in between. eg. > [...] > It will mess up the syments (symbol table entry number) calculation. This raises an interesting question: how do you calculate the number of symbols in .dynsym without using section headers? I figured there'd some kind of "DT_SYMTABNUM" value somewhere but unfortunately the answer doesn't appear to be so straightforward. Judging from the binutils readelf source code you need to use information in the .hash and .gnu.hash sections to calculate the number of entries. To complicate things even more, a binary can contain either .hash or .gnu.hash or both and computing the number of .dynsym entries is different in each case. See binutils/readelf.c:get_num_dynamic_syms, you may need to implement some of this in your patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30077] New: Duplicate definition of typedef struct debuginfod_client in libdwfl
https://sourceware.org/bugzilla/show_bug.cgi?id=30077 Bug ID: 30077 Summary: Duplicate definition of typedef struct debuginfod_client in libdwfl Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: dje at sourceware dot org CC: elfutils-devel at sourceware dot org Target Milestone: --- typedef struct debuginfod_client is defined in both libdwfl/libdwfl.h and in debuginfod.h included by libdwfl/libdwflP.h. Although innocuous, this is invalid C and causes compilation failures with strict compliance. One possible set of patches is: --- libdwfl.h.orig 2023-02-03 15:03:57.669810336 -0500 +++ libdwfl.h 2023-02-03 15:00:53.959921348 -0500 @@ -49,8 +49,10 @@ PC location described by an FDE belonging to Dwfl_Thread. */ typedef struct Dwfl_Frame Dwfl_Frame; +#ifndef ENABLE_LIBDEBUGINFOD /* Handle for debuginfod-client connection. */ typedef struct debuginfod_client debuginfod_client; +#endif /* Callbacks. */ typedef struct --- libdwflP.h.orig 2023-02-03 15:04:29.749793736 -0500 +++ libdwflP.h 2023-02-03 14:53:56.320181520 -0500 @@ -29,6 +29,10 @@ #ifndef _LIBDWFLP_H #define _LIBDWFLP_H1 +#ifdef ENABLE_LIBDEBUGINFOD +#include "../debuginfod/debuginfod.h" +#endif + #include #include #include @@ -41,10 +45,6 @@ #include "../libdw/libdwP.h" /* We need its INTDECLs. */ #include "../libdwelf/libdwelfP.h" -#ifdef ENABLE_LIBDEBUGINFOD -#include "../debuginfod/debuginfod.h" -#endif - typedef struct Dwfl_Process Dwfl_Process; #define DWFL_ERRORS \ -- You are receiving this mail because: You are on the CC list for the bug.
