[Bug tools/28725] eu-ar -x -N COUNT uses instance [COUNT+1] of name
https://sourceware.org/bugzilla/show_bug.cgi?id=28725 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org Ever confirmed|0 |1 Last reconfirmed||2022-08-28 Assignee|unassigned at sourceware dot org |mark at klomp dot org Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Mark Wielaard --- Thanks for the report and analysis. Next time please post output as text instead of an image. I posted a patch that includes a testcase: https://inbox.sourceware.org/elfutils-devel/20220828155746.99653-1-m...@klomp.org/T/#u -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28729] After eu-ar -r added file into archive, it changes file permission
https://sourceware.org/bugzilla/show_bug.cgi?id=28729 Mark Wielaard changed: What|Removed |Added Assignee|unassigned at sourceware dot org |mark at klomp dot org CC||mark at klomp dot org --- Comment #3 from Mark Wielaard --- https://inbox.sourceware.org/elfutils-devel/20220828181034.115031-1-m...@klomp.org/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29434] Memory leak in `dwarf_getscopes`
https://sourceware.org/bugzilla/show_bug.cgi?id=29434 --- Comment #9 from Mark Wielaard --- Created attachment 14302 --> https://sourceware.org/bugzilla/attachment.cgi?id=14302&action=edit dwarf_getscopes debug trace Maybe the following would give us a clue about what is really happening. It should print the DIE offsets that are being visited. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28725] eu-ar -x -N COUNT uses instance [COUNT+1] of name
https://sourceware.org/bugzilla/show_bug.cgi?id=28725 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Mark Wielaard --- commit 6cb01b4ef3cdd4f83d21bbcec72fa66712ac14e6 Author: Mark Wielaard Date: Sun Aug 28 17:46:08 2022 +0200 ar: Correct -N COUNT off-by-one When using instance [COUNT], the instance check is wrong. instance-- == 0 should be --instance == 0. Add a testcase run-ar-N.sh that uses -N COUNT with extract and delete operations checking the right instance was extracted and deleted. https://sourceware.org/bugzilla/show_bug.cgi?id=28725 Reported-by: panxiaohe Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28729] After eu-ar -r added file into archive, it changes file permission
https://sourceware.org/bugzilla/show_bug.cgi?id=28729 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Mark Wielaard --- commit ee188125b10d1588a0536af033d7b7b1bbbaafaf Author: Mark Wielaard Date: Sun Aug 28 19:51:13 2022 +0200 libelf: Correctly decode ar_mode as octal string ar_mode is encoded as an octal ascii string, not decimal. Add a new OCT_FIELD macro to decode it. https://sourceware.org/bugzilla/show_bug.cgi?id=28729 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29614] Fails to build with GCC master + -D_FORTIFY_SOURCE=3
https://sourceware.org/bugzilla/show_bug.cgi?id=29614 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #2 from Mark Wielaard --- Is this with: commit 0873ae782d14e672e8344775e76b7fca0a8b41bf Author: Mark Wielaard Date: Thu Jul 28 15:31:12 2022 +0200 libdwfl: Rewrite reading of ar_size in elf_begin_rand Which has some discussion here: https://inbox.sourceware.org/elfutils-devel/dfd00dc70d07950ce12de7fd20e9171f5325.ca...@klomp.org/T/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29614] Fails to build with GCC master + -D_FORTIFY_SOURCE=3
https://sourceware.org/bugzilla/show_bug.cgi?id=29614 --- Comment #4 from Mark Wielaard --- OK, so, this is with current git trunk. Which version of gcc and glibc are you using? Could you show (make V=1) the exact gcc argument line? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #8 from Mark Wielaard --- Note that we'll need rpm-devel ima-evm-utils-devel openssl-devel rpm-sign to test this (should go into elfutils.spec BuildRequires). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #9 from Mark Wielaard --- To make this slightly easier to review I applied the patch and rebased it to current master. Pushed here: https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=ima -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29714] debuginfod rely on gcc being configured with --enable-linker-build-i
https://sourceware.org/bugzilla/show_bug.cgi?id=29714 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- That is odd, this configure.ac snippet should for build-ids on: # We really want build-ids. Warn and force generating them if gcc was # configure without --enable-linker-build-id AC_CACHE_CHECK([whether the compiler generates build-ids], ac_cv_buildid, [dnl AC_LINK_IFELSE([AC_LANG_PROGRAM()],[ac_cv_buildid=yes; $READELF -n conftest$EXEEXT | grep -q NT_GNU_BUILD_ID || ac_cv_buildid=no],AC_MSG_FAILURE([unexpected compile failure]))]) if test "$ac_cv_buildid" = "no"; then AC_MSG_WARN([compiler doesn't generate build-id by default]) LDFLAGS="$LDFLAGS -Wl,--build-id" fi -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/29498] Is it expected that eu-strip strips .note.GNU-stack
https://sourceware.org/bugzilla/show_bug.cgi?id=29498 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #2 from Mark Wielaard --- Actual SHF_NOTE sections are kept, as are allocated SHF_PROGBITS sections. But this is neither. How does binutils strip know it should keep this section? Does it just hard-code the name? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29434] Memory leak in `dwarf_getscopes`
https://sourceware.org/bugzilla/show_bug.cgi?id=29434 --- Comment #10 from Mark Wielaard --- (In reply to Pablo Galindo Salgado from comment #8) > If you give me a patch adding print statements to libdw/dwarf_getscopes.c > and libdw/libdw_visit_scopes.c I can give you the output. See attachment 14302 on comment #9. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/29695] In libelf.h struct Elf, struct Elf_Scn is defined using typedef and not using #include is not the way to comply with the specification?
https://sourceware.org/bugzilla/show_bug.cgi?id=29695 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED CC||mark at klomp dot org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Mark Wielaard --- libelf.h is a public header. We explicitly don't want to declare complete types for internal data structures. Which is why we don't include or expose libelfP.h. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29711] In libdw.h struct Dwarf, struct Dwarf_Abbrev is defined using typedef and not using #include is not the way to comply with the specification?
https://sourceware.org/bugzilla/show_bug.cgi?id=29711 Mark Wielaard changed: What|Removed |Added Status|WAITING |RESOLVED CC||mark at klomp dot org Resolution|--- |NOTABUG -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/29719] eu-readelf -s=section is confusing
https://sourceware.org/bugzilla/show_bug.cgi?id=29719 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #2 from Mark Wielaard --- I like the WARNING idea. This would also help with something like: $ eu-readelf --symbols=.dynsyms /bin/bash Which currently says nothing, but should warn (it is .dynsym without the s). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29571] Add 'Key to Flags' to eu-readelf output
https://sourceware.org/bugzilla/show_bug.cgi?id=29571 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #2 from Mark Wielaard --- Comment on attachment 14419 --> https://sourceware.org/bugzilla/attachment.cgi?id=14419 elfutils: List flags meaning when running eu-readelf Thanks. But O is for "Ordered" (binutils doesn't seem to have that), N is for "extra OS processing required" (what binutils uses O for), R is for GNU Retain. We don't show 'D' for mbind (we probably should). Nor do we show 'l' for SHF_X86_64_LARGE (we don't even recognize that). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29767] run-backtrace-native-core{,-biarch}.sh Tests Fail
https://sourceware.org/bugzilla/show_bug.cgi?id=29767 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #6 from Mark Wielaard --- I don't fully understand what is going wrong here. The issue is "No modules recognized in core file" error which is produced when dwfl_core_file_report return zero. A zero return means no modules were found from inspecting the core file. Would it be possible to see if the core file produced (inside the test dir) is still there and attach it to this bug report for manual inspection? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29767] run-backtrace-native-core{,-biarch}.sh Tests Fail
https://sourceware.org/bugzilla/show_bug.cgi?id=29767 Mark Wielaard changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #8 from Mark Wielaard --- Works here and for reporter. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/28891] Cross compilation for ARM fails when trying to run i386_gendis
https://sourceware.org/bugzilla/show_bug.cgi?id=28891 --- Comment #2 from Mark Wielaard --- So a solution for people trying to do cross builds directly from git might simply be to do a make dist first and then do a cross from that? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29434] Memory leak in `dwarf_getscopes`
https://sourceware.org/bugzilla/show_bug.cgi?id=29434 --- Comment #16 from Mark Wielaard --- Sorry this is a bit difficult to debug. Would you be able to show the start of the log? It should show how you are calling dwarf_getscopes. I think I have found the RHEL7 glibc debug file. So I can match up some of the DIE offsets, but I have some trouble understanding what is going on. It would also be helpful to see the other log statements in dwarf_getscopes to understand what the first and second calls to __libdw_visit_scopes have as arguments and return value. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29926] debuginfod using deprecated curl (since 7.55.0) API, fails to build with 7.87.0
https://sourceware.org/bugzilla/show_bug.cgi?id=29926 Mark Wielaard changed: What|Removed |Added Resolution|FIXED |--- CC||mark at klomp dot org Last reconfirmed||2023-01-10 Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #4 from Mark Wielaard --- Does the following work for you? diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c index a16165bd..1ce45632 100644 --- a/debuginfod/debuginfod-client.c +++ b/debuginfod/debuginfod-client.c @@ -1336,8 +1336,13 @@ debuginfod_query_server (debuginfod_client *c, /* Only allow http:// + https:// + file:// so we aren't being redirected to some unsupported protocol. */ +#if CURL_AT_LEAST_VERSION(7, 85, 0) + curl_easy_setopt_ck(data[i].handle, CURLOPT_PROTOCOLS_STR, + "http,https,file"); +#else curl_easy_setopt_ck(data[i].handle, CURLOPT_PROTOCOLS, (CURLPROTO_HTTP | CURLPROTO_HTTPS | CURLPROTO_FILE)); +#endif curl_easy_setopt_ck(data[i].handle, CURLOPT_URL, data[i].url); if (vfd >= 0) curl_easy_setopt_ck(data[i].handle, CURLOPT_ERRORBUFFER, https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=protocols_str -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29926] debuginfod using deprecated curl (since 7.55.0) API, fails to build with 7.87.0
https://sourceware.org/bugzilla/show_bug.cgi?id=29926 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #5 from Mark Wielaard --- Sorry, pushed this slightly too early. But the try bots seemed happy. Please feel free to loudly complain if this not actually solved your issue. commit 6560fb26a62ef135a804357ef4f15a47de3e49b3 Author: Mark Wielaard Date: Tue Jan 10 23:20:41 2023 +0100 debuginfod-client: Use CURLOPT_PROTOCOLS_STR for libcurl >= 7.85.0 https://sourceware.org/bugzilla/show_bug.cgi?id=29926 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/28608] elflint elfstrmerge fails with ld.gold
https://sourceware.org/bugzilla/show_bug.cgi?id=28608 --- Comment #5 from Mark Wielaard --- (In reply to Martin Liska from comment #4) > So it fails for: > $ /home/marxin/Programming/elfutils/src/elflint --gnu > /home/marxin/Programming/elfutils/tests/elfstrmerge > section [17] '.rodata': merge flag set but entry size is zero > > $ readelf -SW /home/marxin/Programming/elfutils/tests/elfstrmerge | grep roda > [17] .rodata PROGBITS00402ea0 002ea0 0007bf 00 > AMS 0 0 8 > > As seen the section has SHF_STRING flag, thus having sh_entsize == 0 should > be fine. > > @Mark: Can you please take a look? If both SHF_STRING and SHF_MERGE are set then sh_entsize is the char size (normally 1). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29571] Add 'Key to Flags' to eu-readelf output
https://sourceware.org/bugzilla/show_bug.cgi?id=29571 --- Comment #4 from Mark Wielaard --- (In reply to Martin Liska from comment #3) > @Mark: Can you please push the patch? No, please see comment #2 for various issues that need to be resolved first. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30047] libdw unable to handle DW_TAG_unspecified_type
https://sourceware.org/bugzilla/show_bug.cgi?id=30047 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #2 from Mark Wielaard --- This is slightly tricky, because I think we technically do the right thing here. dwfl_module_return_value_location returns that cannot handle DWARF type description error, which is technically correct, since it is an unspecified_type. dwfl_module_return_value_location can return an error (< 0) which means either bad DWARF or unknown/unhandled type, it can return zero, which means the function has no return value, or it return the number of DWARF expression operations (> 0) that describe how to get the value returned by the function. Sadly we don't have an easy way to distinguish between bad DWARF/type and cannot handle type. I think we can change the testcase though, to check for the special case of DW_TAG_unspecified_type. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30047] libdw unable to handle DW_TAG_unspecified_type
https://sourceware.org/bugzilla/show_bug.cgi?id=30047
Mark Wielaard changed:
What|Removed |Added
Last reconfirmed||2023-01-26
Assignee|unassigned at sourceware dot org |mark at klomp dot org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #3 from Mark Wielaard ---
Created attachment 14633
--> https://sourceware.org/bugzilla/attachment.cgi?id=14633&action=edit
tests: Handle DW_TAG_unspecified_type in funcretval test
This patch just fixes the testcase to check for DW_TAG_unspecified_type as
return type.
With your test binary tests/funcretval now prints:
() _start: returns unspecified type
() main: return value location: {0x50, 0}
But maybe a better fix is for dwfl_module_return_value_location to return zero
(which technically means that the function doesn't have a return value).
Opinions?
--
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 #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 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
--- Comment #8 from Mark Wielaard ---
(In reply to Aaron Merey from comment #7)
> 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.
It has been proposed, but not (yet) adopted:
https://groups.google.com/g/generic-abi/c/9L03yrxXPBc
(sorry, a google groups link, there should be a normal archive, but I cannot
find it right now). If that was adopted and linkers would generate it, then
this question would indeed have a simple answer. Sadly, it isn't :{
> 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.
If there is a .hash section then it is fairly easy, the first word is the
number of symbols the hash/symbol table describes.
If it is a .gnu.hash section then sadly you have to parse and go through the
whole hashtable and count.
There is an implementation already in elfutils, but it is a bit hiden and
obscure if you don't know what you are looking for. Search for "Figure out the
size of the symbol table" in libdwfl/dwfl_module_getdwarf.c.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/30077] Duplicate definition of typedef struct debuginfod_client in libdwfl
https://sourceware.org/bugzilla/show_bug.cgi?id=30077
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #1 from Mark Wielaard ---
(In reply to David Edelsohn from comment #0)
> 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.
Is there a gcc flag that can help us detect this issue?
If the problem is that there cannot be two equal typedefs then we have to solve
this not just in the implementation code but also in the public headers.
If if understand the issue correctly then a program that includes both the
public debuginfod.h and dwfl.h headers (in any order or indirectly) has the
same problem?
Would the following fix it?
diff --git a/debuginfod/debuginfod.h.in b/debuginfod/debuginfod.h.in
index 69c9efd2..4a256ba9 100644
--- a/debuginfod/debuginfod.h.in
+++ b/debuginfod/debuginfod.h.in
@@ -44,7 +44,10 @@
#define DEBUGINFOD_SONAME "@LIBDEBUGINFOD_SONAME@"
/* Handle for debuginfod-client connection. */
+#ifndef _ELFUTILS_DEBUGINFOD_CLIENT_TYPEDEF
typedef struct debuginfod_client debuginfod_client;
+#define _ELFUTILS_DEBUGINFOD_CLIENT_TYPEDEF 1
+#endif
#ifdef __cplusplus
extern "C" {
diff --git a/libdwfl/libdwfl.h b/libdwfl/libdwfl.h
index 9114f7f0..49ad6664 100644
--- a/libdwfl/libdwfl.h
+++ b/libdwfl/libdwfl.h
@@ -50,7 +50,10 @@ typedef struct Dwfl_Thread Dwfl_Thread;
typedef struct Dwfl_Frame Dwfl_Frame;
/* Handle for debuginfod-client connection. */
+#ifndef _ELFUTILS_DEBUGINFOD_CLIENT_TYPEDEF
typedef struct debuginfod_client debuginfod_client;
+#define _ELFUTILS_DEBUGINFOD_CLIENT_TYPEDEF 1
+#endif
/* Callbacks. */
typedef struct
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/30077] Duplicate definition of typedef struct debuginfod_client in libdwfl
https://sourceware.org/bugzilla/show_bug.cgi?id=30077 --- Comment #4 from Mark Wielaard --- (In reply to Sam James from comment #2) > These issues sometimes appear with -flto -Wlto-type-mismatch but not clear > that's the case here. Yes, but typedefs don't define new types, just alias types. Also it looks like this is actually allowed (at least in C11, maybe some compilers didn't accept it before?): - a typedef name may be redefined to denote the same type as it currently does, provided that type is not a variably modified type -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30077] Duplicate definition of typedef struct debuginfod_client in libdwfl
https://sourceware.org/bugzilla/show_bug.cgi?id=30077 --- Comment #5 from Mark Wielaard --- (In reply to David Edelsohn from comment #3) > The struct is needed by libdwfl.h to prototype > > extern debuginfod_client *dwfl_get_debuginfod_client (Dwfl *dwfl); > > but that function is defined in debuginfod-client.c protected by > > #ifdef ENABLE_LIBDEBUGINFOD > > It already is protected where it is referenced by an existing macro. The > problem is the header logic doesn't match the logic in the file that uses > that prototype. > > So, again, it would seem better to include the struct from > debuginfod-client.h directly instead of adding more macros to protect the > headers and types that already are protected. Something like: The public headers are independent and can be used with or without the other being available. And the function must be defined with or without libdebuginfod support available or installed. You cannot use the same guards in the public headers and the implementation sources because they are independent. It might be helpful to know in which configuration you are having this issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30077] Duplicate definition of typedef struct debuginfod_client in libdwfl
https://sourceware.org/bugzilla/show_bug.cgi?id=30077 Mark Wielaard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Mark Wielaard --- (In reply to David Edelsohn from comment #6) > The error is reported if one configures and builds with Clang. Aha. I am not sure things will build with clang. It seems to have a couple more quirks like not supporting some uses of flexible arrays. Note that this really is a pendantic warning and shouldn't be enabled by default imho. You can simply silence it with -Wno-typedef-redefinition > Also, yes, this is a C11 feature, but libdwfl/Makefile.in explicitly invokes > the compiler with -std=gnu99 (AM_CFLAGS). Maybe it is time to switch to gnu11 these days. But since this is in public headers and we don't control the compiler/standard users use lets simply make sure there is only one typedef: commit 45576ab5f24cd39669a418fa8e005b4d04f8e9ca (HEAD -> master) Author: Mark Wielaard Date: Mon Feb 6 10:21:58 2023 +0100 debuginfod: Make sure there is only one typedef for debuginfod_client Both debuginfod.h and libdwfl.h have a simple typedef for struct debuginfod_client. Some compilers pedantically warn when including both headers that such typedefs are only officially supported in C11. So guard them with _ELFUTILS_DEBUGINFOD_CLIENT_TYPEDEF to make them happy. https://sourceware.org/bugzilla/show_bug.cgi?id=30077 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30047] libdw unable to handle DW_TAG_unspecified_type
https://sourceware.org/bugzilla/show_bug.cgi?id=30047 Mark Wielaard changed: What|Removed |Added Attachment #14633|0 |1 is obsolete|| --- Comment #6 from Mark Wielaard --- Created attachment 14657 --> https://sourceware.org/bugzilla/attachment.cgi?id=14657&action=edit backends: Handle DW_TAG_unspecified_type in dwarf_peeled_die_type (In reply to Martin Liska from comment #5) > May I please ping this issue as one needs it with the latest binutils > release (2.40). Yes, thanks. I didn't forget, but I changed my mind how to best handle this issue. See the new patch. This changes the code so that an DW_TAG_unspecified_type is treated just as if the function doesn't have a return type. I think that is a better fix because there might be more code out there that uses dwfl_module_return_value_location and might not handle an error in this case. And there isn't actually much that can be done with an unspecified type, for normal cases it is as if there is no return type. I did adjust the testcase to show how you can see whether it is a missing return type or an unspecified return type in case you program does care. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/30084] readelf.c:handle_bit_registers() sets parameter desc without using it.
https://sourceware.org/bugzilla/show_bug.cgi?id=30084 Mark Wielaard changed: What|Removed |Added Status|NEW |RESOLVED CC||mark at klomp dot org Resolution|--- |FIXED --- Comment #1 from Mark Wielaard --- commit 3c22256392d58dc50324a392c1c9724a834f47d0 Author: Ilya Leoshkevich Date: Wed Feb 8 20:52:22 2023 +0100 readelf: Fix set but not used parameter clang complains: readelf.c:12205:72: error: parameter 'desc' set but not used [-Werror,-Wunused-but-set-parameter] handle_bit_registers (const Ebl_Register_Location *regloc, const void *desc, ^ Mark Wielaard says: It is never really used since as far as I can see we don't have any backend with a core register sets where a register doesn't have a number of bits which isn't a multiple of 8 (only ia64 has some 1 bit registers, but those don't seem part of the core register set). If we do accidentally try to handle such a register having an abort is also not very nice. Lets just warn and return/continue. https://sourceware.org/bugzilla/show_bug.cgi?id=30084 Co-developed-by: Mark Wielaard Signed-off-by: Ilya Leoshkevich -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30047] libdw unable to handle DW_TAG_unspecified_type
https://sourceware.org/bugzilla/show_bug.cgi?id=30047 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Mark Wielaard --- commit f2c522567ad63ac293535fba9704895e685ab5bc Author: Mark Wielaard Date: Thu Jan 26 18:19:15 2023 +0100 backends: Handle DW_TAG_unspecified_type in dwarf_peeled_die_type binutils 2.40 introduces DW_TAG_unspecified_type for assembly functions with an unknown return type. This breaks the run-funcretval.sh testcase because dwfl_module_return_value_location returns an error for such functions because it cannot determine the return value location. Fix that by treating DW_TAG_unspecified_type as if the DIE doesn't have a DW_AT_type. Also update the testcase to explicitly checking for DW_TAG_unspecified_type and printing "returns unspecified type". https://sourceware.org/bugzilla/show_bug.cgi?id=30047 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30085] Negative strides in dwarf_aggregate_size
https://sourceware.org/bugzilla/show_bug.cgi?id=30085 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- I have to admit that I don't understand what it means for a stride to be negative. It looks to me that a stride is like a size, it has to be positive. It would be good to have an example when the stride can be negative. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30085] Negative strides in dwarf_aggregate_size
https://sourceware.org/bugzilla/show_bug.cgi?id=30085 --- Comment #2 from Mark Wielaard --- I asked around and John DelSignore came up with the following fortran example: = array.f95 = program f_prog integer*4, allocatable, target, dimension (:,:) :: big_array integer, dimension (:,:), pointer :: neg_array allocate (big_array(2000,1000)) neg_array => big_array(2000:1:-1,1000:1:-1) end program f_prog So, neg_array is a pointer to an array section where the elements of big_array are reversed. That is, neg_array(x,y) references big_array(2000-x+1,1000-y+1). In this example, the stride makes us go "backwards" into the array. But note that gfortran -g array.f95 produces DW_FORM_exprlocs for the DW_AT_byte_stride because almost all attributes of the array are dynamic at runtime: [c9]array_type abbrev: 10 ordering (data1) col_major (1) data_location(exprloc) [ 0] push_object_address [ 1] deref allocated(exprloc) [ 0] push_object_address [ 1] deref [ 2] lit0 [ 3] ne type (ref4) [72] sibling (ref4) [ 106] [db] subrange_typeabbrev: 1 lower_bound (exprloc) [ 0] push_object_address [ 1] plus_uconst 48 [ 3] deref upper_bound (exprloc) [ 0] push_object_address [ 1] plus_uconst 56 [ 3] deref byte_stride (exprloc) [ 0] push_object_address [ 1] plus_uconst 40 [ 3] deref [ 4] push_object_address [ 5] plus_uconst 32 [ 7] deref [ 8] mul [f0] subrange_typeabbrev: 1 lower_bound (exprloc) [ 0] push_object_address [ 1] plus_uconst 72 [ 3] deref upper_bound (exprloc) [ 0] push_object_address [ 1] plus_uconst 80 [ 3] deref byte_stride (exprloc) [ 0] push_object_address [ 1] plus_uconst 64 [ 3] deref [ 4] push_object_address [ 5] plus_uconst 32 [ 7] deref [ 8] mul [ 106]array_type abbrev: 11 ordering (data1) col_major (1) data_location(exprloc) [ 0] push_object_address [ 1] deref associated (exprloc) [ 0] push_object_address [ 1] deref [ 2] lit0 [ 3] ne type (ref4) [72] [ 114] subrange_typeabbrev: 1 lower_bound (exprloc) [ 0] push_object_address [ 1] plus_uconst 48 [ 3] deref upper_bound (exprloc) [ 0] push_object_address [ 1] plus_uconst 56 [ 3] deref byte_stride (exprloc) [ 0] push_object_address [ 1] plus_uconst 40 [ 3] deref [ 4] push_object_address [ 5] plus_uconst 32 [ 7] deref [ 8] mul [ 129] subrange_typeabbrev: 1 lower_bound (exprloc) [ 0] push_object_address [ 1] plus_uconst 72 [ 3] deref upper_bound (exprloc) [ 0] push_object_address [ 1] plus_uconst 80 [ 3] deref byte_stride (exprloc) [ 0] push_object_address [ 1] plus_uconst 64 [ 3] deref [ 4] push_object_address [ 5] plus_uconst 32 [ 7] deref [ 8] mul Something dwarf_aggregate_size doesn't handle. And even if it could handle the expression, it doesn't know the object address or how to deref memory... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29434] Memory leak in `dwarf_getscopes`
https://sourceware.org/bugzilla/show_bug.cgi?id=29434
--- Comment #17 from Mark Wielaard ---
So the code here changed a little with this patch:
commit b7c7d8776ed46e2237d18fb15c6b72e83cfa259b
Author: Mark Wielaard
Date: Sun Jan 22 00:31:57 2023 +0100
libdw: Search for abstract origin in the correct CU
With gcc -flto the abstract origin of an inlined subroutine
could be in a different CU. dwarf_getscopes might return an
empty scope if it cannot find the abstract origin scope. So
make sure to search in the
We also tried to add the origin match in pc_record directly
in the current inlined scope. This always failed, causing
to do a needless traversal, followed by the full CU scan in
dwarf_getscopes. Just always stop the pc_record search and
then do the CU origin_match in dwarf_getscopes.
Signed-off-by: Mark Wielaard
Which makes the condition of the first check slightly different:
- if (result == 0 && a.scopes != NULL)
-result = __libdw_visit_scopes (0, &cu, NULL, &origin_match, NULL, &a);
+ if (result >= 0 && a.scopes != NULL && a.inlined > 0)
+{
+ /* We like the find the inline function's abstract definition
+ scope, but that might be in a different CU. */
+ cu.die = CUDIE (a.inlined_origin.cu);
+ result = __libdw_visit_scopes (0, &cu, NULL, &origin_match, NULL, &a);
+}
So with that I think my proposed patch in comment #3 might work.
But I have not been able to replicate the issue. So cannot easily check.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/29434] Memory leak in `dwarf_getscopes`
https://sourceware.org/bugzilla/show_bug.cgi?id=29434 --- Comment #18 from Mark Wielaard --- I could replicate a leak when there was an error looking up the inlined scopes, so I submitted the patch to fix that: https://inbox.sourceware.org/elfutils-devel/2023023901.1089881-1-m...@klomp.org/T/#u Hopefully that also fixes the original issue (which I have been unable to replicate). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29434] Memory leak in `dwarf_getscopes`
https://sourceware.org/bugzilla/show_bug.cgi?id=29434 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #19 from Mark Wielaard --- I hope this (plus the other changes to dwarf_getscopes) will fix the original issue too. It should be part of 0.189 (which should be released this week). If it didn't solve the issue please feel free to reopen this bug or file a new one. commit e24d8a4a3ea106608bb3e8d33c4639cf71d0f08d Author: Mark Wielaard Date: Wed Feb 22 23:34:00 2023 +0100 libdw: Fix dwarf_getscopes memory leak on error When there is an error in dwarf_getscopes after the initial scopes have been allocated, e.g. when looking for the inlined scopes, then the scopes would leak. Fix this by explicitly free the scopes on error. https://sourceware.org/bugzilla/show_bug.cgi?id=29434 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29472] Support querying the debuginfod-server for metadata
https://sourceware.org/bugzilla/show_bug.cgi?id=29472 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #5 from Mark Wielaard --- Followup patch: https://patchwork.sourceware.org/project/elfutils/patch/20221101142306.gl16...@redhat.com/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29176] run-backtrace-native-biarch.sh seems to fail on Ubuntu Jammy
https://sourceware.org/bugzilla/show_bug.cgi?id=29176 --- Comment #10 from Mark Wielaard --- (In reply to Jan-Benedict Glaw from comment #9) > Is there already a decision on whether or not the tests should pass when > there's no dbgsym package installed for libc? The test should pass even without the dbgsym package. The unwinder should work without any extra debuginfo installed. It (now) also fails on debian-testing in the buildbot: https://builder.sourceware.org/buildbot/#/builders/elfutils-debian-testing-x86_64 PASS: run-backtrace-native.sh SKIP: run-backtrace-native-core.sh FAIL: run-backtrace-native-biarch.sh SKIP: run-backtrace-native-core-biarch.sh The skips there are because there are no core files created. The issue seems to be a testcase issue, where it expects "real" symbol names, even if it doesn't really matter. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29176] run-backtrace-native-biarch.sh seems to fail on Ubuntu Jammy
https://sourceware.org/bugzilla/show_bug.cgi?id=29176 --- Comment #11 from Mark Wielaard --- Proposed patch: https://patchwork.sourceware.org/project/elfutils/patch/20230304213534.1448550-1-m...@klomp.org/ Did pass on the elfutils-debian-amd64 builder: https://builder.sourceware.org/buildbot/#/builders/205/builds/58 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/30196] [0.189 regression] configure.ac contains Bashisms
https://sourceware.org/bugzilla/show_bug.cgi?id=30196 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Mark Wielaard --- You are completely right. Committed as: commit a9834d7df68afde4ee44ee8fef888cf7e799171a Author: Mark Wielaard Date: Sun Mar 5 13:09:34 2023 +0100 configure.ac contains Bashisms Autoconf scripts are supposed to be written in POSIX-compatible shell language. elfutils commits 0ffe2874e75d48cb88936e119e5284ff2bf664d9 and 3fa98a6f29b0f370e32549ead7eb897c839af980 introduced Bashisms to configure.ac that cause errors when /bin/sh is not Bash. Example error when /bin/sh is Dash: ./configure: 8748: test: xyes: unexpected operator The cause of the error is the use of a non-existent == operator in expressions passed to the 'test' built-in command. POSIX shell specifies only an = operator for testing string equality. * configure.ac: Replace == by = in use_msan and enable_demangler comparisons. https://sourceware.org/bugzilla/show_bug.cgi?id=30196 Reported-by: Matt Whitlock Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29176] run-backtrace-native-biarch.sh seems to fail on Ubuntu Jammy
https://sourceware.org/bugzilla/show_bug.cgi?id=29176 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #13 from Mark Wielaard --- (In reply to Jan-Benedict Glaw from comment #12) > Pulling in that patch works for me as well. Great. Pushed as: commit a7f65495258933eaf361e82eb325c9d826b455d5 (HEAD -> master) Author: Mark Wielaard Date: Sat Mar 4 21:55:56 2023 +0100 tests: skip '(null)' symname frames in backtrace tests Some setups might have some frames for unknown (null) functions in the thread backtrace. Skip these frames instead of failing immediately. * tests/backtrace.c (callback_verify): Check and skip nulls_seen. https://sourceware.org/bugzilla/show_bug.cgi?id=29176 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/30251] eu-elflint is broken on LoongArch
https://sourceware.org/bugzilla/show_bug.cgi?id=30251 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED CC||mark at klomp dot org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Mark Wielaard --- Thanks, that looks perfect. Pushed as: commit b2871fa8d430e2c5fb39e3ebc6745ea32f1bddb4 Author: Alexey Sheplyakov Date: Mon Mar 20 18:45:02 2023 +0400 LoongArch: implemented a basic machine flag check With this patch I can use eu-elflint to verify LoongArch ELF binaries. Previously eu-elflint was complaining about invalid machine flags: $ ./src/elflint --gnu-ld ./src/elflint invalid machine flags: 0x43 $ echo $? 1 * backends/loongarch_symbol.c (loongarch_init): Hook machine_flag_check. * backends/loongarch_symbol.c (loongarch_machine_flag_check): New function. https://sourceware.org/bugzilla/show_bug.cgi?id=30251 Signed-off-by: Alexey Sheplyakov -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30272] Unwinding multithreaded musl applications fails
https://sourceware.org/bugzilla/show_bug.cgi?id=30272 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #3 from Mark Wielaard --- This does seem a bug in musl which doesn't seem to add enough cfi as the email thread mentioned in comment #2 says. Note that glibc does explicitly mark the end of stack in clone in cfi by undefining the pc: sysdeps/unix/sysv/linux/aarch64/clone.S:cfi_undefined (x30) sysdeps/unix/sysv/linux/aarch64/clone3.S: cfi_undefined (x30) sysdeps/unix/sysv/linux/alpha/clone.S: cfi_undefined(ra) sysdeps/unix/sysv/linux/csky/abiv2/clone.S: cfi_undefined (lr) sysdeps/unix/sysv/linux/i386/clone.S: cfi_undefined (eip); sysdeps/unix/sysv/linux/i386/clone3.S: cfi_undefined (eip) sysdeps/unix/sysv/linux/loongarch/clone.S: cfi_undefined (1) sysdeps/unix/sysv/linux/loongarch/clone3.S: cfi_undefined (1) sysdeps/unix/sysv/linux/m68k/clone.S: cfi_undefined (pc) /* Mark end of stack */ sysdeps/unix/sysv/linux/mips/clone.S: cfi_undefined ($31) sysdeps/unix/sysv/linux/nios2/clone.S: cfi_undefined (ra) sysdeps/unix/sysv/linux/riscv/clone.S: cfi_undefined (ra) sysdeps/unix/sysv/linux/s390/s390-32/clone.S: cfi_undefined (r14) sysdeps/unix/sysv/linux/s390/s390-64/clone.S: cfi_undefined (r14) sysdeps/unix/sysv/linux/x86_64/clone.S: cfi_undefined (rip); sysdeps/unix/sysv/linux/x86_64/clone3.S:cfi_undefined (rip) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30221] Negative cache should differentiate failure types
https://sourceware.org/bugzilla/show_bug.cgi?id=30221 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #13 from Mark Wielaard --- Has this issue been fixed with the fixe from comment #9 https://sourceware.org/cgit/elfutils/commit/?id=5527216460c6131527c27b06dada015b67525966 And/Or was it caused by the sqlite performance regression mentioned in comment #9 -- 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 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Mark Wielaard --- commit 4d8de4b2fa05495d69d09e1a3d335f24d6bf33ee Author: Di Chen Date: Mon Mar 27 10:01:05 2023 +0800 readelf: display dynamic symtab without section headers This commit adds a new option "-D/--use-dynamic" to support printing the dynamic symbol table from the PT_DYNAMIC segment. By using the PT_DYNAMIC segment, eu-readelf can go through the contents of dynamic section entries and the values of each tag. From that, we can get the address and size of the dynamic symbol table, the address of the string table, etc. By using the new option "-D/--use-dynamic", eu-readelf can list the symbols without section headers. Example: $ ./src/readelf -Ds a.out 0: 0 NOTYPE LOCAL DEFAULTUNDEF 1: 0 FUNCGLOBAL DEFAULTUNDEF __libc_start_main@GLIBC_2.34 (2) 2: 0 NOTYPE WEAK DEFAULTUNDEF __gmon_start__ https://sourceware.org/bugzilla/show_bug.cgi?id=28873 Signed-off-by: Di Chen -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29696] intermittent libmicrohttpd assertion failures related to socket fd closing
https://sourceware.org/bugzilla/show_bug.cgi?id=29696
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #2 from Mark Wielaard ---
Very nice find. How did you catch this btw?
Are there any tools that help find such a "double closes"?
If not maybe we can teach valgrind --track-fds=yes about it, which already can
track fd leaks, so it shouldn't be too hard to make it also detect double/bad
closes.
The patch seems obviously correct to me. Nice to now log close () failures,
which should help catch similar issues early.
Small nitpick. The "}else{" is a bit of a style break with the rest of the
code, which would say:
...
}
else
{
...
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug tools/28495] Add support for SHT_RELR to eu-readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=28495 Mark Wielaard changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |mark at klomp dot org --- Comment #4 from Mark Wielaard --- (In reply to Adam Jackson from comment #3) > SHT_RELR is shipping now: Thanks. I had missed this. I have a patch for adding support for RELR. But want to make sure I have the interface right first: https://groups.google.com/g/generic-abi/c/xVqXhwB8T9M -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #11 from Mark Wielaard --- So as far as I understand this is now the three commits on top of users/rgoldber/try-bz28204c: https://sourceware.org/cgit/elfutils/log/?h=users/rgoldber/try-bz28204c I find it slightly easier when patches are simply posted to the mailinglist (using git send-email). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #12 from Mark Wielaard --- In config/profile.csh.in and config/profile.sh.in the prefix variable is explicitly set and no longer unset. Is that deliberate? In debuginfod_validate_imasig the file_data = malloc(data_len); depends on the (externally) given file size. It is then read in one pread call. And the whole buffer is then given to EVP_DigestUpdate. Note that this might create a giant malloc buffer, which might trigger OOM. pread might succeed with fewer bytes than given. It needs to be called in a loop. But it would be better if we could read it and feed it to EVP_DigestUpdate in (small) chunks. Is EACCESS the right error code to return when the signature couldn't be checked/is invalid? That is the same as when we get CURLE_REMOTE_ACCESS_DENIED. It might be good if it was an unique error code so users can know that the file was not trusted. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #13 from Mark Wielaard --- The configure checks might need to check whether the rpm development headers define the needed constants. On an rhel8 system this gives: checking for headerGet in -lrpm... yes checking for imaevm_hash_algo_from_sig in -limaevm... yes checking for EVP_MD_CTX_new in -lcrypto... yes but... Making all in debuginfod CXX debuginfod.o elfutils/debuginfod/debuginfod.cxx: In function ‘MHD_Response* handle_buildid_r_match(bool, int64_t, const string&, const string&, const string&, int*)’: elfutils/debuginfod/debuginfod.cxx:2026:47: error: ‘RPMSIGTAG_FILESIGNATURES’ was not declared in this scope if (!sig_hdr || 1 != headerGet(sig_hdr, RPMSIGTAG_FILESIGNATURES, &sig_tag_data, HEADERGET_ALLOC)) ^~~~ elfutils/debuginfod/debuginfod.cxx:2026:47: note: suggested alternative: ‘RPMTAG_FILESIGNATURES’ if (!sig_hdr || 1 != headerGet(sig_hdr, RPMSIGTAG_FILESIGNATURES, &sig_tag_data, HEADERGET_ALLOC)) ^~~~ RPMTAG_FILESIGNATURES make[2]: *** [Makefile:657: debuginfod.o] Error 1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #14 from Mark Wielaard --- I think it is the user/distro packager who should decide which ima-certs to ship. I don't think elfutils should come with ima-certs itself. Why is there a "permissive" policy? What is the use case for this? Should the policy be per debuginfod url? So you can point to an official distro debuginfod which must be in enforcing mode, but can add a local one with an "ignore" policy. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #15 from Mark Wielaard --- The basic idea having a collection of certs, and an signature for each file that is transported with the fetch operation that will be checked against those trusted certs is understandable. But I must admit that I am a little lost in the rpm and koji mechanisms to extract those signatures. How easy will it be to extend to other platforms that might store such signatures in different ways? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204
--- Comment #17 from Mark Wielaard ---
(In reply to Ryan Goldberg from comment #16)
> (In reply to Mark Wielaard from comment #12)
> > In config/profile.csh.in and config/profile.sh.in the prefix variable is
> > explicitly set and no longer unset. Is that deliberate?
> Taking a look at both files they seem to still contain `unset prefix` as
> their last lines. Would that not do the trick?
Yes it would. I was just confused why it was needed.
But I now see that @sysconfdir@ is used and that uses $prefix.
So that explains why you need it defined.
> > In debuginfod_validate_imasig the file_data = malloc(data_len); depends on
> > the (externally) given file size. It is then read in one pread call. And the
> > whole buffer is then given to EVP_DigestUpdate. Note that this might create
> > a giant malloc buffer, which might trigger OOM. pread might succeed with
> > fewer bytes than given. It needs to be called in a loop. But it would be
> > better if we could read it and feed it to EVP_DigestUpdate in (small)
> > chunks.
> Sure, just looked at the docs for EVP_DigestUpdate and seems like this
> change should be pretty straightforward.
>
> > Is EACCESS the right error code to return when the signature couldn't be
> > checked/is invalid? That is the same as when we get
> > CURLE_REMOTE_ACCESS_DENIED. It might be good if it was an unique error code
> > so users can know that the file was not trusted.
> How do you feel about EPERM? Not exactly its usage but we've used up a good
> number of the more applicable ones with the CURL errors (EACCESS, EINVAL)
Yes, EPERM sounds like a good pick. It is unlikely to be produced by any other
operation (unless there are file seals in play).
> (In reply to Mark Wielaard from comment #14)
> > I think it is the user/distro packager who should decide which ima-certs to
> > ship. I don't think elfutils should come with ima-certs itself.
> From what I've seen finding the correct certificates for IMA verification
> has been pretty tricky, so distributing a copy of these (at least early
> certificates) might be a good idea. Eventually the intention is for these
> certs to be shipped in a known location which we can easily add to the
> search path, but until then having a copy seems like the best bet imho.
>
> > Why is there a "permissive" policy? What is the use case for this?
> It might be that a user wants to be aware of what's going on but does not
> need to be quite so strict on rejection. Permissive won't allow incorrect
> signatures but will allow say an unsigned file whereas an enforcing client
> will reject anything that does not come with a valid signature
Doesn't that give a false sense of "security"?
It still rejects some stuff, but doesn't really protect against "falsifying"
files, all a server has to do is not provide an IMA
If it is just to see what would happen if enabling ima file checking, then it
probably shouldn't reject anything. In that case it should warn for both
missing and invalid signatures, but still accept them.
But in general I like less "modes".
> > Should the policy be per debuginfod url? So you can point to an official
> > distro debuginfod which must be in enforcing mode, but can add a local one
> > with an "ignore" policy.
> I was thinking of keeping things simple, but don't have anything against
> moving to a per URL sort of approach. What kind of format would you want for
> such a thing? For urls foo:bar:baz would we want something like
> ignore::enforcing where blanks are the default? Don't love this structure
> since it seems a little unwieldy. I'll think on a better format for it.
Maybe prefixing or postfixing URLS with + or adding the name of the cert?
DEBUGINFOD_URLS="https://debuginfod.fedoraproject.org/+FEDORACERTNAME"; ?
Yeah, gets ugly quick :{
But I think a common use case will be having the main distro debuginfod server
in enforcing mode and your local/org debuginfod server in trusting mode.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug tools/27501] eu-readelf hang while process crafted file
https://sourceware.org/bugzilla/show_bug.cgi?id=27501 --- Comment #2 from Mark Wielaard --- Apparently someone created a CVE for this bug: https://nvd.nist.gov/vuln/detail/CVE-2021-33294 Note that we don't consider this a security issue: https://sourceware.org/cgit/elfutils/tree/SECURITY Since most elfutils tools are run in short-lived, local, interactive, development context rather than remotely "in production", we generally treat malfunctions as ordinary bugs rather than security vulnerabilities. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/30772] dwarflint checking for specification recursion
https://sourceware.org/bugzilla/show_bug.cgi?id=30772 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- libdw dwarf_attr_integrate does prevent cycles by limiting the chain of DW_AT_abstract_origin and DW_AT_specification to 16 (arbitrary number). On a different level, DW_AT_import can also create cycles (or rather infinite imports). __libdw_visit_scopes does contain some cycle detection. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #20 from Mark Wielaard --- (In reply to Frank Ch. Eigler from comment #18) > > Doesn't that give a false sense of "security"? > > It still rejects some stuff, but doesn't really protect against "falsifying" > > files, all a server has to do is not provide an IMA > > Yes, but trusted servers won't just do that. But isn't the idea of checking the IMA signatures that you don't have to trust the server providing the debuginfo files as the distro intended them? > > If it is just to see what would happen if enabling ima file checking, then > > it probably shouldn't reject anything. In that case it should warn for both > > missing and invalid signatures, but still accept them. > > The difference between missing and invalid is that the latter is KNOWN bad. > An invalid signature is evidence that the file has a problem. And a missing signature is UNKNOWN bad? So both are bad in some way. Which imho means that if we support some kind of permissive mode, then it should explicitly warn for both kind of baddness. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28495] Add support for SHT_RELR to eu-readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=28495 --- Comment #5 from Mark Wielaard --- https://inbox.sourceware.org/elfutils-devel/20230823220211.1942430-1-m...@klomp.org/T/#u https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=relr With that eu-readelf -r /usr/lib64/libc.so.6 now gives: Relocation section [11] '.rela.dyn' at offset 0x243e8 contains 86 entries: Offset TypeValue Addend Name 0x001d0c88 X86_64_64 0x001dd440 +0 _res 0x001d3d70 X86_64_TPOFF64 00 +56 0x001d3d78 X86_64_TPOFF64 00 +48 0x001d3d80 X86_64_TPOFF64 00 +88 0x001d3d88 X86_64_TPOFF64 00 +72 0x001d3d90 X86_64_TPOFF64 00 +80 0x001d3d98 X86_64_TPOFF64 00 +96 0x001d3da0 X86_64_TPOFF64 00+120 0x001d3da8 X86_64_TPOFF64 00+128 0x001d3dc0 X86_64_TPOFF64 00 +24 0x001d3dd0 X86_64_TPOFF64 00 +40 0x001d3de8 X86_64_TPOFF64 00 +16 0x001d3e28 X86_64_TPOFF64 00+116 0x001d3f48 X86_64_TPOFF64 00 +0 0x001d3fc0 X86_64_TPOFF64 00 +8 0x001d3fd0 X86_64_TPOFF64 00 +32 0x001d3db0 X86_64_GLOB_DAT 0x001dd860 +0 svc_max_pollfd 0x001d3db8 X86_64_GLOB_DAT 0x001d5518 +0 obstack_alloc_failed_handler 0x001d3dc8 X86_64_GLOB_DAT 0x001d4810 +0 __ctype_toupper 0x001d3dd8 X86_64_GLOB_DAT 0x001dc5d0 +0 loc1 0x001d3de0 X86_64_GLOB_DAT 00 +0 _dl_argv 0x001d3df0 X86_64_GLOB_DAT 0x001dc5d8 +0 __libc_single_threaded 0x001d3df8 X86_64_GLOB_DAT 0x0009d150 +0 free 0x001d3e00 X86_64_GLOB_DAT 0x001dc220 +0 re_syntax_options 0x001d3e08 X86_64_GLOB_DAT 0x001dd880 +0 rpc_createerr 0x001d3e10 X86_64_GLOB_DAT 0x001d5868 +0 stdout 0x001d3e18 X86_64_GLOB_DAT 0x001d4800 +0 __ctype32_toupper 0x001d3e20 X86_64_GLOB_DAT 0x001d4428 +0 opterr 0x001d3e30 X86_64_GLOB_DAT 0x001db780 +0 getdate_err 0x001d3e38 X86_64_GLOB_DAT 0x001dc338 +0 __curbrk 0x001d3e40 X86_64_GLOB_DAT 0x001dc5c8 +0 loc2 0x001d3e48 X86_64_GLOB_DAT 0x001d5538 +0 program_invocation_name 0x001d3e50 X86_64_GLOB_DAT 0x001d41e0 +0 __fpu_control 0x001d3e58 X86_64_GLOB_DAT 00 +0 __libc_enable_secure 0x001d3e60 X86_64_GLOB_DAT 0x001d56a0 +0 _IO_2_1_stderr_ 0x001d5680 X86_64_64 0x001d56a0 +0 _IO_2_1_stderr_ 0x001d5860 X86_64_64 0x001d56a0 +0 _IO_2_1_stderr_ 0x001d3e68 X86_64_GLOB_DAT 0x001dcf78 +0 __rcmd_errstr 0x001d3e70 X86_64_GLOB_DAT 0x001d4828 +0 __ctype_b 0x001d3e78 X86_64_GLOB_DAT 0x001dc5a8 +0 error_print_progname 0x001d3e80 X86_64_GLOB_DAT 0x001d5860 +0 stderr 0x001d3e88 X86_64_GLOB_DAT 0x001d43e8 +0 obstack_exit_failure 0x001d3e90 X86_64_GLOB_DAT 00 +0 __libc_stack_end 0x001d3e98 X86_64_GLOB_DAT 0x001dd9e0 +0 __key_encryptsession_pk_LOCAL 0x001d3ea0 X86_64_GLOB_DAT 00 +0 _rtld_global_ro 0x001d3ea8 X86_64_GLOB_DAT 0x001dcb00 +0 argp_program_version 0x001d3eb0 X86_64_GLOB_DAT 0x001dd940 +0 svcauthdes_stats 0x001d3eb8 X86_64_GLOB_DAT 0x001d44e8 +0 __check_rhosts_file 0x001d3ec0 X86_64_GLOB_DAT 0x001d442c +0 optind 0x001d3ec8 X86_64_GLOB_DAT 0x001d4aa0 +0 _IO_2_1_stdin_ 0x001d57e8 X86_64_64 0x001d4aa0 +0 _IO_2_1_stdin_ 0x001d5870 X86_64_64 0x001d4aa0 +0 _IO_2_1_stdin_ 0x001d3ed0 X86_64_GLOB_DAT 0x001d5530 +0 program_invocation_short_name 0x001d3ed8 X86_64_GLOB_DAT 0x001d4808 +0 __ctype32_tolower 0x001d3ee0 X86_64_GLOB_DAT 0x001dc5a4 +0 error_message_count 0x001d3ee8 X86_64_GLOB_DAT 0x001d4424 +0 optopt 0x001d3ef0 X86_64_GLOB_DAT 0x001d4820 +0 __ctype32_b 0x001d3ef8 X86_64_GLOB_DAT 0x001d5da0 +0 _nl_msg_cat_cntr 0x001d3f00 X86_64_GLOB_DAT 0x001db688 +0 __daylight 0x001d3f08 X86_64_GLOB
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #22 from Mark Wielaard --- (In reply to Ryan Goldberg from comment #21) > (In reply to Mark Wielaard from comment #20) > > But isn't the idea of checking the IMA signatures that you don't have to > > trust the server providing the debuginfo files as the distro intended them? > But this will allow for the case of a trusted server which only has some of > it's RPMs per-file signed. Take for instance a server which has the RPMs for > f36,37,38. The f36 files don't have signatures so using enforcing here is > too strict since we are ok just letting a client know that these ones are > unverifiable, but we still want to be able to reject any of the invalid ones > for f38 This still feels odd. Since you cannot distinguish between non-sig f36 package (okish?) and non-sig f38 packages (bad?). I think you have to either trust or reject all non-sig packages from such a server. > > So both are bad in some way. Which imho means that if we support some kind > > of permissive mode, then it should explicitly warn for both kind of > > baddness. > In the permissive mode you'll get: > * "the signature is valid" for valid sigs > * "ALERT: this download is being rejected since the IMA signature could not > be verified" for invalid sigs > * "the signature could not be verified" otherwise I'll look at the code to see if I understand what this means in practice. Are those the messages presented to the user (in verbose mode? always?). And does this mean all three cases warn (or only the second and third)? And is it just a message or does it also mean actual rejection in some cases? > So we do warn for both kinds of bad, we just don't reject the 'unknown' bad But how is 'unknown' bad different from invalid signature bad? I think you should assume that if there is no signature, then the signature is by definition invalid (assume it has a signature of ). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #24 from Mark Wielaard --- BTW. How does this interact with the "section" queries? If the server doesn't support "section" then the debuginfod-client fallback to fetching "debuginfo" or "executable" should do the signature checking. But there doesn't seem to be a way to make (client side) signature checking work when fetching "section". Does this mean that in enforcing mode we always need to use the fallback mode? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #25 from Mark Wielaard --- So I am looking at users/rgoldber/try-bz28204d but it isn't clear you want to merge that in separate commits or squashed together. I am comparing to users/rgoldber/try-bz28204c which I believe is the previous version reviewed. It really makes things a lot easier if the actual patches that are intended to be merged are posted (with a description of what was changed since the last review). So as far as I can tell the new series has been rebased from commit 35e059b654224b1a01d05877b13582c74c692388 to 27a84961f7a061b83f10f7e02bf433c229d6537a. Good. That is just 3 commits. - configure.ac checks updated. - debuginfod/debuginfod-client.c introduces ima_policy_t Includes an "undefined" policy? debuginfod_validate_imasig updated to read/digest in chunks of DATA_SIZE. Is the k += DATA_SIZE correct? Can't pread return an n < DATA_SIZE? If the cert_paths = strdup (...) fails cert_paths gets assigned a static string? Won't that crash the strtok calls or the free (cert_path) call? In debuginfod_query_server the server_urls are parsed to see te ima policy, as described debuginfod-client-config.7 Sorry, have to stop for a bit. Will try to look at the rest later. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204
--- Comment #26 from Mark Wielaard ---
(In reply to Ryan Goldberg from comment #23)
> (In reply to Mark Wielaard from comment #22)
> > This still feels odd. Since you cannot distinguish between non-sig f36
> > package (okish?) and non-sig f38 packages (bad?). I think you have to either
> > trust or reject all non-sig packages from such a server.
> I see where you're coming from but what policy would you use for
> https://debuginfod.fedoraproject.org?
I think that depends on which release I am using.
Normally I would be debugging/profiling local programs/libraries.
So for f38 I would like to a policy that checks the ima signatures.
If I am on f36 or if e.g. I expect to be inspecting a non-local core file based
on f36 then I would not use a policy that checks the ima signatures, because
they might not be there.
> > I'll look at the code to see if I understand what this means in practice.
> > Are those the messages presented to the user (in verbose mode? always?). And
> > does this mean all three cases warn (or only the second and third)? And is
> > it just a message or does it also mean actual rejection in some cases?
>
> 2008 if(NULL != url_ima_policies && ignore !=
> url_ima_policies[committed_to])
> 2009 {
> 2010 int result = debuginfod_validate_imasig(c, target_cache_tmppath, fd);
> 2011 if(0 == result)
> 2012 {
> 2013 if (vfd >= 0) dprintf (vfd, "the signature is valid\n");
> 2014 }
> 2015 else if(EINVAL == result || enforcing ==
> url_ima_policies[committed_to])
> 2016 {
> 2017 // All invalid signatures are rejected.
> 2018 // Additionally in enforcing mode any non-valid signature is
> rejected, so by reaching
> 2019 // this case we do so since we know it is not valid. Note - this
> not just invalid signatures
> 2020 // but also signatures that cannot be validated
> 2021 if (vfd >= 0) dprintf (vfd, "ALERT: this download is being
> rejected since the IMA signature could not be verified\n");
> 2022 rc = -EPERM;
> 2023 goto out2;
> 2024 }
> 2025 else
> 2026 {
> 2027 // By default we are permissive, so since the signature isn't
> invalid we
> 2028 // give it the benefit of the doubt
> 2029 if (vfd >= 0) dprintf (vfd, "the signature could not be
> verified\n");
> 2030 }
> 2031 }
>
> Here is the relevant snippet
Thanks.
So if the policy is "ignore" nothing is checked.
Otherwise the ima signature is checked.
If the policy is enforcing we return EPERM.
Otherwise we return the target/OK, independent of the result of the ima sig
check.
All notices are printed if we are in verbose mode.
BTW. The last notice isn't really accurate.
The signature might have been verified. In which case it was invalid.
In practice "permissive" (or default) mode is no different from "ignore".
Which imho makes permissive mode not very useful.
So I think we shouldn't have a permissive mode, just use ignore.
If we have an permissive mode then I think it should work like the selinux
permissive mode.
That is, it should always check the signature, but instead of failing with
EPERM, it should
always produce a warning (whether or not we are in verbose mode or not).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libelf/30729] Build failure with upcoming LLD 17 (elf_scncnt: undefined version: ELFUTILS_1.0 during linking phase of libelf.so)
https://sourceware.org/bugzilla/show_bug.cgi?id=30729 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #2 from Mark Wielaard --- So just to be clear, the issue is that elf_scncnt is only mentioned in the libelf.map but doesn't actually exist (it never seems to have been)? Does simply removing it from libelf.map resolve this issue? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/30729] Build failure with upcoming LLD 17 (elf_scncnt: undefined version: ELFUTILS_1.0 during linking phase of libelf.so)
https://sourceware.org/bugzilla/show_bug.cgi?id=30729 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Mark Wielaard --- Thanks for testing. Pushed that fix: commit 09e61a65953ed814d9e970f7f9ffb9c2d8cda477 Author: Mark Wielaard Date: Mon Aug 28 20:23:41 2023 +0200 libelf: Remove elf_scncnt from libelf.map elf_scncnt was never implemented. It was probably an old name for elf_getshnum (which was the deprecated name of the elf_getshdrnum alias). Just remove it from the map file * libelf/libelf.map (ELFUTILS_1.0): Remove elf_scncnt. https://sourceware.org/bugzilla/show_bug.cgi?id=30729 Reported-by: Kostadin Shishmanov Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28495] Add support for SHT_RELR to eu-readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=28495 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Mark Wielaard --- commit 39f2c500542f69c2f1a13fd0ae4eaa5778d2ed8d Author: Mark Wielaard Date: Sun Jul 23 23:14:31 2023 +0200 libelf, readelf, elflint: Add RELR support Handle RELR as defined here: https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/YT2RrjpMAwAJ Introduce new ELF_T_RELR Elf_Type and handle it for SHT_RELR. Check various properties in elflint. Print RELR relocations in readelf. Just the entries with -U. Just the addresses with -N. And addresses plus symbol/offsets by default. Also add a test to check that gelf.h works with the system elf.h. * libebl/eblsectiontypename.c (ebl_section_type_name): Add RELR to knownstype. * libelf/elf32_updatenull.c (updatenull_wrlock): Handle sh_entsize for SHT_RELR. * libelf/gelf.h (GElf_Relr): New typedef for Elf64_Relr. * libelf/gelf_fsize.c (__libelf_type_sizes): Add ELF_T_RELR. * libelf/gelf_xlate.c (__elf_xfctstom): Likewise. * libelf/gelf_xlate.h: Add RELR as FUNDAMENTAL. * libelf/libelf.h (Elf_Type): Add ELF_T_RELR. Add RELR defines/typedefs if undefined in system elf.h. * libelf/libelfP.h: Define ELF32_FSZ_RELR and ELF64_FSZ_RELR. * src/elflint.c (check_reloc_shdr): Check she_entsize for ELF_T_RELR. (check_relr): New function. (check_dynamic): Handle DT_RELR. (special_sections): Add SHT_RELR. (check_sections): Call check_relr. * src/readelf.c (print_relocs): Also accept a Dwfl_Module. (handle_relocs_relr): New function. (print_dwarf_addr): Make static and declare early. (process_elf_file): Pass dwflmod to print_relocs. (handle_dynamic): Handle DT_RELRSZ and DTRELRENT. * system-elf-gelf-test.c: New test. * Makefile.am (TESTS): Add system-elf-gelf-test. (check_PROGRAMS): Likewise. (system_elf_gelf_test_CPPFLAGS): New variable. (system_elf_gelf_test_LDADD): Likewise. https://sourceware.org/bugzilla/show_bug.cgi?id=28495 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204
--- Comment #28 from Mark Wielaard ---
(In reply to Ryan Goldberg from comment #27)
> (In reply to Mark Wielaard from comment #24)
> > BTW. How does this interact with the "section" queries?
> Since these aren't ima verifiable anyways wdyt of just skipping verification
> all together (i.e treat that query in the same way as the ignore policy)
Assuming ima verification is so one can be sure bits are what a distro really
distributes I don't think a default to ignore policy is useful. I think in
enforcing mode there is no good way to fetch just the section data and the
client has to fall back onto requesting the full executable or debuginfo file,
verify the ima signature, and then locally extract the section data (of course
this is somewhat inefficient).
> Tweaking the above to something like:
> 2008if(NULL != url_ima_policies && ignore !=
> url_ima_policies[committed_to] && NULL == section) { ... }
>
> (In reply to Mark Wielaard from comment #25)
> > Includes an "undefined" policy?
> Just used internally when parsing DEBUGINFOD_URLS
> > Is the k += DATA_SIZE correct? Can't pread return an n < DATA_SIZE?
> Fixed
> > If the cert_paths = strdup (...) fails cert_paths gets assigned a static
> > string?
> Fixed
Thanks. It would be good to post a patch with these fixes (maybe rebased to
current git trunk). So it is more clear what exact change you intent to commit.
> (In reply to Mark Wielaard from comment #26)
> > If we have an permissive mode then I think it should work like the selinux
> > permissive mode.
> > That is, it should always check the signature, but instead of failing with
> > EPERM, it should
> > always produce a warning (whether or not we are in verbose mode or not).
> I would be ok with this kind of permissive mode
This would have my preference too. Or just simply have either an ignore or
enforcing mode.
But from our discussion on irc I think Frank believes it is better to see
permissive mode as a kind of possible checksum mode. I am not sure about that
use case.
Given that we have reliable transports a checksum mode might be something for
the server to do (assuming the server doesn't trust its own storage). The
server could do an ima check before sending any file and simply don't sent it
if the ima check(sum) fails. This then would be independent of the client ima
check (enforced or not).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug general/30812] ../libelf/gelf.h:32:10: fatal error: libelf.h: No such file or directory
https://sourceware.org/bugzilla/show_bug.cgi?id=30812 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- That is interesting. How are you building it? The test should use the gelf.h and libelf.h from the current source tree, but the system install libelf. O... I see the testcase includes them as ../libelf/libelf.h and ../libelf/gelf.h, but then gelf.h itself does an #include which comes from the system path. hmmm, so this is a build without libelf already installed. Which of course is a valid setup. But have to think how to reorder the testcase to work that way... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/30812] ../libelf/gelf.h:32:10: fatal error: libelf.h: No such file or directory
https://sourceware.org/bugzilla/show_bug.cgi?id=30812 Mark Wielaard changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |mark at klomp dot org --- Comment #2 from Mark Wielaard --- The following seems to work: diff --git a/tests/Makefile.am b/tests/Makefile.am index 49069ccf..32b18e6e 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -807,9 +807,14 @@ nvidia_extended_linemap_libdw_LDADD = $(libelf) $(libdw) # We want to test the libelf headers against the system elf.h header. # Don't include any -I CPPFLAGS. Except when we install our own elf.h. +# For the gelf test we do want our own libelf.h, but nothing else. +BUILT_SOURCES = libelf.h +CLEANFILES += libelf.h +libelf.h: $(top_srcdir)/libelf/libelf.h + cp $< $@ if !INSTALL_ELFH system_elf_libelf_test_CPPFLAGS = -system_elf_gelf_test_CPPFLAGS = +system_elf_gelf_test_CPPFLAGS = -I. else system_elf_libelf_test_CPPFLAGS = -I$(top_srcdir)/libelf system_elf_gelf_test_CPPFLAGS = -I$(top_srcdir)/libelf -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/30812] ../libelf/gelf.h:32:10: fatal error: libelf.h: No such file or directory
https://sourceware.org/bugzilla/show_bug.cgi?id=30812 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Mark Wielaard --- commit 276c367be0807301652817c0df071c90ae3c276b Author: Mark Wielaard Date: Sun Sep 3 18:25:56 2023 +0200 tests: Fix system_elf_gelf_test build without system libelf.h If there is no system libelf.h then the building of system-elf-gelf-test fails with: ../libelf/gelf.h:32:10: fatal error: libelf.h: No such file or directory This is because although the testcase includes the headers as ../libelf/libelf.h and ../libelf/gelf.h, gelf.h itself does an Fix this by putting a copy of libelf.h in the build test directory and using -I. for building system-elf-gelf-test. * tests/Makefile.am (BUILT_SOURCES): New for libelf.h. (CLEANFILES): Add libelf.h. (libelf.h): New target that copies srdir libelf.h. (system_elf_gelf_test_CPPFLAGS): Add -I. https://sourceware.org/bugzilla/show_bug.cgi?id=30812 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug spam/25705] zeex gans
https://sourceware.org/bugzilla/show_bug.cgi?id=25705 Mark Wielaard changed: What|Removed |Added Product|elfutils|web Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED Assignee|unassigned at sourceware dot org |nobody at sourceware dot org CC||mark at klomp dot org Component|libasm |spam --- Comment #1 from Mark Wielaard --- spam -- You are receiving this mail because: You are on the CC list for the bug.
[Bug spam/25710] Bug
https://sourceware.org/bugzilla/show_bug.cgi?id=25710 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|general |spam Assignee|unassigned at sourceware dot org |nobody at sourceware dot org Product|elfutils|web CC||mark at klomp dot org Resolution|--- |INVALID --- Comment #1 from Mark Wielaard --- spam -- You are receiving this mail because: You are on the CC list for the bug.
[Bug spam/25726] iya jipaosy
https://sourceware.org/bugzilla/show_bug.cgi?id=25726 Mark Wielaard changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nobody at sourceware dot org Status|UNCONFIRMED |RESOLVED Product|elfutils|web Resolution|--- |INVALID CC|elfutils-devel at sourceware dot o | |rg | Component|debuginfod |spam --- Comment #1 from Mark Wielaard --- spam -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25728] Starting debubinfod with --port=0 is not documented
https://sourceware.org/bugzilla/show_bug.cgi?id=25728 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- Is this behavior actually useful or does --port=0 work by accident? I don't see this (http_port == 0) documented for MHD_start_daemon. So I would actually just reject it: diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx index 7c7e85eb..39736351 100644 --- a/debuginfod/debuginfod.cxx +++ b/debuginfod/debuginfod.cxx @@ -422,7 +422,8 @@ parse_opt (int key, char *arg, case 'v': verbose ++; break; case 'd': db_path = string(arg); break; case 'p': http_port = (unsigned) atoi(arg); - if (http_port > 65535) argp_failure(state, 1, EINVAL, "port number"); + if (http_port == 0 || http_port > 65535) +argp_failure(state, 1, EINVAL, "port number"); break; case 'F': scan_files = true; break; case 'R': -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25728] Starting debubinfod with --port=0 is not documented
https://sourceware.org/bugzilla/show_bug.cgi?id=25728 Mark Wielaard changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Mark Wielaard --- Proposed to just disable this undocumented "feature" because it doesn't seem very useful: https://sourceware.org/pipermail/elfutils-devel/2020q1/002568.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/25743] [patch] Update Ukrainian translation
https://sourceware.org/bugzilla/show_bug.cgi?id=25743 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED CC||mark at klomp dot org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Mark Wielaard --- Thanks, right in time for the next release. Applied as: commit 01bb77a5e4464e2d40811fc78635b076a28aad0f (HEAD -> master) Author: Yuri Chornoivan Date: Sat Mar 28 15:03:22 2020 +0200 Update Ukrainian translation Signed-off-by: Yuri Chornoivan -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498
--- Comment #7 from Mark Wielaard ---
We need a way to generate symbol versions without having to use (top-level)
inline assembly. It appears GCC 10 will provide this:
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
We should try to use this to define the symbol version macros (OLD_VERSION,
NEW_VERSION, COMPAT_VERSION_NEWPROTO, COMPAT_VERSION) in lib/eu-config.h
symver ("name2@nodename")
On ELF targets this attribute creates a symbol version. The name2 part of
the parameter is the actual name of the symbol by which it will be externally
referenced. The nodename portion should be the name of a node specified in the
version script supplied to the linker when building a shared library. Versioned
symbol must be defined and must be exported with default visibility.
__attribute__ ((__symver__ ("foo@VERS_1"))) int
foo_v1 (void)
{
}
Will produce a .symver foo_v1, foo@VERS_1 directive in the assembler
output.
It’s an error to define multiple version of a given symbol. In such case an
alias can be used.
__attribute__ ((__symver__ ("foo@VERS_2")))
__attribute__ ((alias ("foo_v1")))
int symver_foo_v1 (void);
This example creates an alias of foo_v1 with symbol name symver_foo_v1
which will be version VERS_2 of foo.
Finally if the parameter is "name2@@nodename" then in addition to creating
a symbol version (as if "name2@nodename" was used) the version will be also
used to resolve name2 by the linker.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug tools/25793] eu-readelf -w dumps incomplete even if debuginfod available
https://sourceware.org/bugzilla/show_bug.cgi?id=25793
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #1 from Mark Wielaard ---
(In reply to Frank Ch. Eigler from comment #0)
> 0.179 eu-readelf -w /bin/ls on fedora31 x86-64 gladly produces a
> disassembly of the .eh_frame* content of the stripped binary. However, it
> is unable/unwilling to download debuginfo to fill in for example 'eu-readelf
> -winfo' data.
That is by design. [eu-]readelf just shows the data of the given ELF file. That
is why .eh_frame is dumped, but .debug_frame isn't (if it isn't available as
separate .debug file).
(Note that -winfo doesn't work with eu-readelf:
I think it would be a surprising change if [eu-]readelf would now by default
start looking up auxiliary files to dump data from. But maybe it could do this
in a special mode. There is some precedent to do that with an extra mode, with
--debug-dump=info+ which does lookup split-DWARF (--debug-dump=info does not).
readelf: print split CUs when given --debug-dump=info+
To show the difference between "regular" CUs and split CUs print
offsets and references between { and } instead of [ and ].
When --debug-dump=info+ is given (implied by -w) instead of
--debug-dump=info any skeleton unit will be immediately followed
by the corresponding split compile unit (from the .dwo file).
Maybe we could extend the + notation to other sections which could be looked up
through some extension/auxiliary lookup mechanism from the main file?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498 --- Comment #8 from Mark Wielaard --- I proposed a patch to use the new gcc 10 symver attribute to define symbol versioning: https://sourceware.org/pipermail/elfutils-devel/2020q2/002606.html This should help with using LTO since it makes the function symbols and versions visible to the compiler (before they were "hidden" inside asm statements). But I haven't tried to build all of elfutils with LTO enabled yet. How do you configure elfutils to enable LTO? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498 Mark Wielaard changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #12 from Mark Wielaard --- (In reply to Martin Liška from comment #9) > (In reply to Mark Wielaard from comment #8) > > I proposed a patch to use the new gcc 10 symver attribute to define symbol > > versioning: > > > > https://sourceware.org/pipermail/elfutils-devel/2020q2/002606.html > > > > This should help with using LTO since it makes the function symbols and > > versions visible to the compiler (before they were "hidden" inside asm > > statements). > > There's an ongoing effort that will extend .symver GAS syntax: > https://sourceware.org/bugzilla/show_bug.cgi?id=25295 > > Later then, the GCC will utilize the new syntax. Interesting, thanks for the reference. I also added a comment to the GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200#c43 because the current syntax (not supporting triple @ variant) makes things a bit cumbersome. This is partly because the interaction between linker version script and assembler .symver isn't really documented fully. The assembler .symver should override what is in the linker version script, but it doesn't fully. In particular, as shown by this hack, the linker might still add a (default) version to a symbol, even if the assembler already added a version. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498
--- Comment #13 from Mark Wielaard ---
(In reply to Martin Liška from comment #11)
> (In reply to kloczek from comment #10)
> > > I would add a configure option --enable-lto that will append -flto to
> > > {C,LD}FLAGS.
> >
> > Please don't do that.
> >
> > LTO can be driven using only env variable.
> >
> > % CFLAGS="" LDFLAGS="" ./configure
>
> Works for me.
Sorry, but what are the clto_cflags and lto_ldflags precisely?
And we now (also) have some c++ code for the debuginfod server, which I assume
needs some CXXFLAGS too?
> > Please use KISS principle and do not implement something which can be
> > already done other way *without* touching existing code.
> >
> > PS. Changing {C,LD}FLAGS is not only part of using LTO. You need to pass NM,
> > RANLIB and AR env variables.
>
> Not necessarily. Typical Linux systems, like openSUSE, utilize auto-loading
> mechanism of LTO plugins:
On Fedora32 that doesn't seem to work with:
$ CFLAGS="-O2 -g -flto" CXXFLAGS="-O2 -g -flto" LDFLAGS="-flto" ./configure
--enable-maintainer-mode
$ make
[...]
ar: elf_version.o: plugin needed to handle lto object
ranlib libelf.a
ranlib: libelf.a(elf_version.o): plugin needed to handle lto object
Am I using the wrong flags?
Or are the default ar and ranlib tools not build with the correct flags?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug general/25831] Assertion failure in eu-objdump
https://sourceware.org/bugzilla/show_bug.cgi?id=25831 Mark Wielaard changed: What|Removed |Added Last reconfirmed||2020-04-16 CC||mark at klomp dot org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Mark Wielaard --- It is bad code and so correct to reject it. But we can reject it without asserting and just printing "(bad)". Proposed patch: https://sourceware.org/pipermail/elfutils-devel/2020q2/002619.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/25832] aarch64 fails to compile with musl
https://sourceware.org/bugzilla/show_bug.cgi?id=25832 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- Looks like glibc is correct. The linux uapi headers also declare arm64 vregs as an uint128_t array. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498 --- Comment #15 from Mark Wielaard --- Thanks for that setup. It allows me to play a bit more with LTO. One commit to help with one issue has been pushed already: commit 39f28eaf8c821d71d57ffc759655ec4168d0bead Author: Mark Wielaard Date: Thu Apr 16 17:45:31 2020 +0200 libdwfl: Initialize bits to NULL in dwfl_standard_find_debuginfo for LTO. GCC10 LTO is too smart (and somewhat cryptic): find-debuginfo.c: In function ‘dwfl_standard_find_debuginfo’: debuginfod-client.c:85:8: error: ‘bits’ may be used uninitialized in this function [-Werror=maybe-uninitialized] find-debuginfo.c:360:24: note: ‘bits’ was declared here lto1: all warnings being treated as errors So it inlines __libdwfl_debuginfod_find_debuginfo into dwfl_standard_find_debuginfo and since it cannot see into the function pointer (*fp_debuginfod_find_debuginfo), it assumes that build_id_bit (== bits in dwfl_standard_find_debuginfo) will be used by the called function and it might not be initialized. But if you read the code the there is a check for build_id_len > 0 to see whether bits is or isn't initialized before using bits. But gcc isn't smart enough to figure that out. Maybe that actually should be an heuristic gcc lto should use. If the callchain I am inlining is so deep that I cannot figure out maybe-uninitialized variables anymore I should stop inlining. For now just help GCC out and initialize bits to NULL. Signed-off-by: Mark Wielaard I am not sure what to do about the various error: stack usage might be unbounded [-Werror=stack-usage=] when "linking" the various tools. If you look at the src/Makefile.am you'll see that for each file we make sure to build with -Wno-stack-usage= But since lto1 combines both files that have been compiled with and without that warning flag it reappears again. The only workaround for now is using CFLAGS="... -Wno-error=stack-usage=" when building inside the src/ directory. Which is a little ugly because it will disable the error also when it should be checked... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498 --- Comment #16 from Mark Wielaard --- Various self tests fail when everything is build with LTO. In particular various files contain .gnu.lto_ sections with SHF_EXCLUDE set. This is an interesting flag since it is treated as a generic section flag, but really isn't. I proposed the following patch to work around it for now: https://sourceware.org/pipermail/elfutils-devel/2020q2/002625.html But see also the following discussion: https://sourceware.org/pipermail/binutils/2020-April/110691.html Another issue is that ET_REL files don't contain normal DWARF .debug_ sections, but .gnu.debuglto_.debug_* sections. Which libdw doesn't recognize. Still working on that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498 --- Comment #17 from Mark Wielaard --- (In reply to Mark Wielaard from comment #16) > Various self tests fail when everything is build with LTO. > [...] > Another issue is that ET_REL files don't contain normal DWARF .debug_ > sections, but .gnu.debuglto_.debug_* sections. Which libdw doesn't > recognize. Still working on that. Patch to handle those posted: https://sourceware.org/pipermail/elfutils-devel/2020q2/002627.html With this and the SHF_EXCLUDE patch there are only 2 more test failures, test-nlist and run-varlocs-self.sh, which look like they can be solved by be a bit more careful what to check (test-nlist relies on symbols being in the source file declared order, run-varlocs-self.sh relies on ET_REL debuginfo containing addresses). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498 --- Comment #18 from Mark Wielaard --- (In reply to Mark Wielaard from comment #17) > With this and the SHF_EXCLUDE patch there are only 2 more test failures, > test-nlist and run-varlocs-self.sh, which look like they can be solved by be > a bit more careful what to check (test-nlist relies on symbols being in the > source file declared order, run-varlocs-self.sh relies on ET_REL debuginfo > containing addresses). Patches for both issues have been posted: https://sourceware.org/pipermail/elfutils-devel/2020q2/002629.html https://sourceware.org/pipermail/elfutils-devel/2020q2/002630.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/25838] eu-readelf crashes due to a general protection fault
https://sourceware.org/bugzilla/show_bug.cgi?id=25838 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- Sorry, I cannot replicate this on either x86_64 or i686. Running the reproducer under valgrind doesn't show any issues. Could you provide more details how you configured and build the binary? How exactly are you invoking it and what exactly is the complete output? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/25831] Assertion failure in eu-objdump
https://sourceware.org/bugzilla/show_bug.cgi?id=25831 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- Pushed the fix: commit 25d40a626d36c140c8bb309f410f25af2836ec9b Author: Mark Wielaard Date: Thu Apr 16 15:41:57 2020 +0200 libcpu: Replace assert with goto invalid_op for bad prefix. https://sourceware.org/bugzilla/show_bug.cgi?id=25831 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498 --- Comment #19 from Mark Wielaard --- The following now works with current git master: $ export AR=gcc-ar RANLIB=gcc-ranlib NM=gcc-nm $ autoreconf -f -v -i $ ./configure --enable-maintainer-mode CFLAGS="-O2 -g -flto -flto-partition=none -Wno-error=stack-usage=" CXXFLAGS="-O2 -g -flto -flto-partition=none" $ make -j4 $ make check -j4 # TOTAL: 218 # PASS: 216 # SKIP: 2 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 The -flto-partition=none workaround is still needed issues with symbol versioning (even with the new gcc symver support we'll still get multiple defined symbols). The -Wno-error=stack-usage= is needed for "linking" the various tools in src (they have -Wno-stack-usage= in src/Makefile.am, but it links with some code in lib/ which doesn't...) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498 --- Comment #22 from Mark Wielaard --- kloczek, re comment #20 and comment #21, is that with the latest git master sources? It looks like it is missing several code and testsuite fixes. In particular are you sure you have the following patches: commit e2fc0b737c1d55becda1f13dceec315a5589820a Author: Mark Wielaard Date: Thu Apr 16 18:48:58 2020 +0200 elflint: Allow SHF_EXCLUDE as generic section flag when --gnu is given. commit d6185d33fb2a65b4c3cbc73c5529937debdd2568 Author: Mark Wielaard Date: Fri Apr 17 11:31:40 2020 +0200 libdw, readelf: Handle GCC LTO .gnu.debuglto_ prefix. commit 51cfbaabefd6d5ebdd7513b876daf78d07470f8c Author: Mark Wielaard Date: Fri Apr 17 12:21:46 2020 +0200 tests: Build test-nlist with minimal CFLAGS to guarantee symbol order. commit 554352ded723042572a91200d05fdb075b1a1ea3 Author: Mark Wielaard Date: Fri Apr 17 12:31:15 2020 +0200 tests: Run run-varlocs-self.sh for object files with --exprlocs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.179: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498 Mark Wielaard changed: What|Removed |Added Summary|0.176: isn't LTO ready |0.179: isn't LTO ready -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/26043] eu-addr2line debuginfo-path option with relative path doesn't find file:line information
https://sourceware.org/bugzilla/show_bug.cgi?id=26043 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- Could you show what is under the demo/build directory? I am trying to understand where the DWARF debug data is. Is it in the main binaries, in separate .debug files in the directory of the main binary, in a separate file in a separate directory, are the main binaries using build-ids and/or .gnu.debuglink sections? --debuginfo-path (for utilities using dwfl_standard_argp) will set the .debuginfo_path of the Dwfl_callbacks. This is then used to find debug files. The way these paths are used is as follows (from libdwfl.h): /* These standard find_elf and find_debuginfo callbacks are controlled by a string specifying directories to look in. If `debuginfo_path' is set in the Dwfl_Callbacks structure and the char * it points to is not null, that supplies the string. Otherwise a default path is used. If the first character of the string is + or - that enables or disables CRC32 checksum validation when it's necessary. The remainder of the string is composed of elements separated by colons. Each element can start with + or - to override the global checksum behavior. This flag is never relevant when working with build IDs, but it's always parsed in the path string. The remainder of the element indicates a directory. Searches by build ID consult only the elements naming absolute directory paths. They look under those directories for a link named ".build-id/xx/yy" or ".build-id/xx/yy.debug", where "xxyy" is the lower-case hexadecimal representation of the ID bytes. In searches for debuginfo by name, if the remainder of the element is empty, the directory containing the main file is tried; if it's an absolute path name, the absolute directory path (and any subdirectory of that path) containing the main file is taken as a subdirectory of this path; a relative path name is taken as a subdirectory of the directory containing the main file. Hence for /usr/bin/ls, the default string ":.debug:/usr/lib/debug" says to look in /usr/bin, then /usr/bin/.debug, then the path subdirs under /usr/lib/debug, in the order /usr/lib/debug/usr/bin, then /usr/lib/debug/bin, and finally /usr/lib/debug, for the file name in the .gnu_debuglink section (or "ls.debug" if none was found). */ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/26043] eu-addr2line debuginfo-path option with relative path doesn't find file:line information
https://sourceware.org/bugzilla/show_bug.cgi?id=26043 --- Comment #4 from Mark Wielaard --- (In reply to devel.origin from comment #2) > The debug info is in the .build-id/ dir: ../../demo/build/.build-id/ab/... > > Seems consistent with what the comment says. Should I make a real test > example (the current is just a very good fictional one)? If you could create a reproducer that would be great. I think the issue is that the build-id searches simply skip relative directories. Specifically this in libdwfl/dwfl_build_id_find_elf.c: /* Only absolute directory names are useful to us. */ if (dir[0] != '/') continue; While for find-debuginfo.c we have: /* A relative path says to try a subdirectory of that name in the main file's directory. */ I believe the idea is that lookups by build-id can be done without having a (main) file. While file based lookup always starts with a (main) file, and relative paths can be resolved based on the main file directory. It might make sense to try build-id lookups using the same relative path logic if we do have a (main) file to start with. BTW. How did you end up with this setup? Is there a development tool that creates a structure like that? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/25838] eu-readelf crashes due to a general protection fault
https://sourceware.org/bugzilla/show_bug.cgi?id=25838 --- Comment #4 from Mark Wielaard --- Sorry, I cannot replicate even when building elfutils with CC=afl-gcc, with or without AFL_HARDEN=1. Could you provide more information on how exactly you configure, build and run. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/25227] "eu-nm --extern" skips first symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=25227 --- Comment #10 from Mark Wielaard --- Proposed patch: https://sourceware.org/pipermail/elfutils-devel/2020q2/002713.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
https://sourceware.org/bugzilla/show_bug.cgi?id=25509 --- Comment #7 from Mark Wielaard --- So there are two ideas here: - Split --disable-debuginfod which currently disables building debuginfod (the server), libdebuginfod (the library) and debuginfod-find (the helper binaries) in two: --disable-debuginfod to disable building of the server. --disable-libdebuginfod to disable building of the library and helper binary. - Introduce a dummy-libdebuginfod which has the same interface as libdebuginfod, so applications (during bootstrapping) can link to it. But which would not link against libcurl and all functions would simply fail. I assume that --disable-libdebuginfod would mean you cannot have --enable-debuginfod (because debuginfod links against libdebuginfod). And that --enable-dummy-libdebuginfod would imply --disable-libdebuginfod because they provide the same library. I assume that debuginfod-find would be build if either --enable-libdebuginfod or --enable-dummy-libdebuginfod is given (in the last case it would simply not do anything useful, but would show the dummy "works"). -- You are receiving this mail because: You are on the CC list for the bug.
