[Bug libdw/27805] libdwfl: Unable to extract source line information for RISC-V binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27805 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #2 from Mark Wielaard --- (In reply to Jim Wilson from comment #1) > Using readelf -wr to look at the debug_aranges section, I see entries like > > Length: 44 > Version: 2 > Offset into .debug_info: 0x987 > Pointer Size: 4 > Segment Size: 0 > > AddressLength > > 20400132 0002 > 20400134 003a > > > An address/length entry of 0/0 is supposed to mark the end of the list, but > here we have one at the beginning. This is confusing elfutils which is > trying to move byte by byte through the aranges section. > libdw/dwarf_aranges.c has > /* Two zero values mark the end. */ > if (range_address == 0 && range_length == 0) > break; > and then assumes that the next entry is immediately following, which it > isn't, and it ends up reading garbage. binutils seems to be using the > length field to find the last entry. And readelf is ignoring the 0/0 end of > list rule so that we can see the invalid entries. > > There are a lot of aranges that have 0/0 entries not at the end of the list. Any idea where they come from? And what does it look like when using -gdwarf-5? You should get a .debug_rnglists section in that case which has explicit end of list markers (before DWARF5 the double zero addresses are interpreted as end of list). -- You are receiving this mail because: You are on the CC list for the bug.
Re: PATCH: PR27783: debuginfod: fetch default DEBUGINFOD_URLS from systemwide file
Hi Frank, On Mon, May 03, 2021 at 09:05:42AM -0400, Frank Ch. Eigler via Elfutils-devel wrote: > > [...] But I think that is the nice things about using the > > environment variable to indicate debuginfod-client should be used in > > a specific environment. [...] > > This is only a way of making the default more of an opt-out than an > opt-in, and put it into a -single- systemwide spot (instead of two > profile.* files plus all the opt-in systemd unit files). A daemon > -disinterested- in participating could set the same env var to be an > empty string. But I think an interactive user environment is different from a standalone running daemon environment. So I think it makes sense they might use diffent opt-in/out strategies. > > Also some distros already seem to rely on the profile files, so > > removing them now seems like a bad idea. > > Well, nothing stops them from continuing to ship the same files, they > don't need to come from elfutils upstream. > > Anyway all that said, I'm neutral on this change. Any other opinions? It is really a distro decission I guess. How do different distros handle this? Cheers, Mark
[Bug libdw/27805] libdwfl: Unable to extract source line information for RISC-V binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27805
--- Comment #3 from Jim Wilson ---
My first thought was linkonce/comdat, but that is used by C++ and would have
shown up before. So that leaves -gc-sections. I can reproduce with a simple
example.
rohan:2010$ cat tmp.c
extern int sub1 (int);
extern int sub2 (int);
extern int sub3 (int);
extern int sub4 (int);
int main (void) { return sub2 (sub4 (0)); }
rohan:2011$ cat tmp2.c
int sub1 (int i) {return i + 10; }
int sub2 (int i) {return i + 20; }
int sub3 (int i) {return i - 10; }
int sub4 (int i) {return i - 20; }
rohan:2012$ riscv32-unknown-elf-gcc -O2 tmp.c tmp2.c -ffunction-sections
-Wl,-gc-sections -g
rohan:2013$ readelf -wr a.out
Contents of the .debug_aranges section:
Length: 28
Version: 2
Offset into .debug_info: 0x0
Pointer Size: 4
Segment Size: 0
AddressLength
00010074 000e
Length: 52
Version: 2
Offset into .debug_info: 0x7c
Pointer Size: 4
Segment Size: 0
AddressLength
00010114 0004
00010118 0004
rohan:2014$
I get the same result with an x86_64-linux compiler. And I get the same result
with -gdwarf-5.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/27805] libdwfl: Unable to extract source line information for RISC-V binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27805 --- Comment #4 from Jim Wilson --- Actually I just noticed with the x86_64-linux compiler I'm getting addresses of 0 but lengths of 4 which would be OK. Length: 92 Version: 2 Offset into .debug_info: 0x8c Pointer Size: 8 Segment Size: 0 AddressLength 0004 0620 0004 0004 0630 0004 This is an Ubuntu 18.04 gcc-7.6 toolchain. Not clear why it is different. -- You are receiving this mail because: You are on the CC list for the bug.
Re: PATCH: PR27784 debuginfod: notify interactive clients one time about usage
Hi -
OK, how about this?
diff --git a/config/profile.sh.in b/config/profile.sh.in
index aa228a0dcd16..aec9e7df30f3 100644
--- a/config/profile.sh.in
+++ b/config/profile.sh.in
@@ -1,4 +1,18 @@
if [ -n "@DEBUGINFOD_URLS@" ]; then
- DEBUGINFOD_URLS="${DEBUGINFOD_URLS-}${DEBUGINFOD_URLS:+
}@DEBUGINFOD_URLS@"
- export DEBUGINFOD_URLS
+DEBUGINFOD_URLS="${DEBUGINFOD_URLS-}${DEBUGINFOD_URLS:+ }@DEBUGINFOD_URLS@"
+debuginfod_cachedir="${XDG_CACHE_HOME-$HOME/.cache}/debuginfod_client"
+notify_p="$debuginfod_cachedir"/notify_p
+if [ ! -f "$notify_p" ]; then
+msg="NOTICE: This system is configured to auto-download debuginfo from:
+$DEBUGINFOD_URLS
+NOTICE: Set your \$DEBUGINFOD_URLS differently if desired."
+if [ -x /usr/bin/notify-send -a -n "$DISPLAY" ]; then
+/usr/bin/notify-send "$msg"
+ fi
+echo "$msg" >&2
+mkdir -p "$debuginfod_cachedir"
+ touch "$notify_p"
+fi
+unset debuginfod_cachedir notify_p msg
+export DEBUGINFOD_URLS
fi
Re: Missing .gnu_debugdata section on ARM platform when libdw is used by systemd-coredump
Hi Tino, On Tue, 2021-05-04 at 14:15 +0200, Tino Mettler via Elfutils-devel wrote: > I have a system running on 2 different architectures: AMD64 and ARM. > When a coredump happens, I want systemd-coredump to generate a stack > trace of the crashing application. Systemd depends on elfutils for > this feature. I use binaries with minidebuginfo (the LZMA compressed > symbol table in the .gnu_debugdata section) on both architectures. > > I get a stack trace on AMD64, but not on ARM. While debugging this, I > saw that find_aux_sym() from dwfl_module_getdwarf.c does not find a > .gnu_debugdata section when iterating through the ELF using > elf_nextscn(). > > However, it finds a .gnu_debuglink section. I inspected the > executable and verified that it contains a .gnu_debugdata section and > it looks fine. Interestingly, there is no .gnu_debuglink section in > the executable despite elf_nextscn() seems to find one. > > It looks like libdw does not process the actual executable, but a > modified variant, and the .gnu_debugdata section gets lost at some > point on my ARM device. Can you give me a hint where I need to look > at? Both devices run a different kernel with a different > configuration. Could that be related? > > I also tried gdb using the coredump file from systemd-coredump and > the same executable, and a stack trace worked as expected. If possible you might want to post the core file and/or executables somewhere so others can inspect them. I am not completely sure how the .gnu_debugdata (aux symbols) is related. Are you getting a backtrace, but not function symbols for the addresses? For ARM it might depend on whether the executable contains an .eh_frame sections. If it has (or the .debug file has an .debug_frame section) then libdw should be able to produce a backtrace. But there are also ARM binaries which only come with IDX data, which libdw doesn't handle. Cheers, Mark
Re: Storing package metadata in ELF objects
Hi Luca,
On Tue, 2021-05-04 at 14:43 +0100, Luca Boccassi wrote:
> On Fri, 2021-04-30 at 19:57 +0200, Mark Wielaard wrote:
> > Is there a list of default keys (and their canonical spelling, upper-
> > lower-Camel_Case, etc.)? If there is, could we have a "debuginfod" key
> > with as value an URL pointing to the debuginfod server URL where the
> > embedded build-id executable, debuginfo and sources can be found?
> > https://sourceware.org/elfutils/Debuginfod.html
>
> The "Implementation" section of the spec lists the "main" fields:
>
> https://systemd.io/COREDUMP_PACKAGE_METADATA/
>
> (source for that is
> https://github.com/systemd/systemd/blob/main/docs/COREDUMP_PACKAGE_METADATA.md
> )
>
> Would you like to send a PR to update it and add that field?
Sorry, I don't have a github account. But attached is a patch for to
document it and one for the package-notes generator to add an --
debuginfod argument (maybe the distro should set a default value for
that?) Hopefully those patches could be applied somehow.
Thanks,
Mark
From 176dde09fcfeff9bff97fbf65d47a641dbd2fa3a Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Thu, 6 May 2021 03:05:02 +0200
Subject: [PATCH] docs/COREDUMP_PACKAGE_METADATA.md: Add debuginfod key
Signed-off-by: Mark Wielaard
---
docs/COREDUMP_PACKAGE_METADATA.md | 5 +
1 file changed, 5 insertions(+)
diff --git a/docs/COREDUMP_PACKAGE_METADATA.md b/docs/COREDUMP_PACKAGE_METADATA.md
index ab7c4596de..b7be9ca797 100644
--- a/docs/COREDUMP_PACKAGE_METADATA.md
+++ b/docs/COREDUMP_PACKAGE_METADATA.md
@@ -26,6 +26,10 @@ Thus it becomes desirable to add additional metadata to a binary at build time,
`systemd-coredump` and other services analyzing core files are able to extract said
metadata simply from the core file itself, without external dependencies.
+And in case external dependencies and network are available the core file
+should also include the debuginfod server URL that can provide the original
+executable, debuginfo and sources to facilitate debugging.
+
## Implementation
This document will attempt to define a common metadata format specification, so that
@@ -58,6 +62,7 @@ Value: a JSON string with the structure described below
"name":"coreutils",
"version": "4711.0815.fc13.arm32",
"osCpe": # A CPE name for the operating system, `CPE_NAME` from os-release is a good default
+ "debuginfod": "https://debuginfod.fedoraproject.org";
}
```
--
2.18.4
From 6264605699cbac02ed3060cc1ff6497b32e90382 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Thu, 6 May 2021 03:13:57 +0200
Subject: [PATCH] generate-package-notes.py: Add --debuginfod argument
Signed-off-by: Mark Wielaard
---
generate-package-notes.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/generate-package-notes.py b/generate-package-notes.py
index c0b5d98..92126f7 100755
--- a/generate-package-notes.py
+++ b/generate-package-notes.py
@@ -71,6 +71,7 @@ def parse_args():
p.add_argument('--package-version')
p.add_argument('--cpe')
p.add_argument('--rpm', metavar='NEVRA')
+p.add_argument('--debuginfod')
opts = p.parse_args()
@@ -143,6 +144,8 @@ def generate_section(opts):
else:
data['os'] = read_os_release('ID')
data['osVersion'] = read_os_release('VERSION_ID')
+if opts.debuginfod:
+data['debuginfod'] = opts.debuginfod
json = json_serialize(data)
--
2.18.4
Re: Windows build of libelf (or more)?
Hi Stephan, On Tue, 2021-05-04 at 14:47 +, Stephan Tobies via Elfutils-devel wrote: > To refresh an existing library based on the old libelf code (mr511), > I am looking for a way to compile (or cross-compile) the libelf of > the elfutils for Windows. If have been searching the mailing list > archive but have not found any pointers in that direction. > > Is anybody aware of a way to compile libelf into a standalone Windows > DLL? > > Any pointers would be appreciated! The Qt project had some windows libraries: https://code.qt.io/cgit/qt-creator/elfutils.git/ https://download.qt.io/development_releases/prebuilt/elfutils/ See also https://sourceware.org/pipermail/elfutils-devel/2018q3/001166.html Cheers, Mark
Re: Windows build of libelf (or more)?
The Qt project had some windows libraries: https://code.qt.io/cgit/qt-creator/elfutils.git/ https://download.qt.io/development_releases/prebuilt/elfutils/ Those are somewhat outdated, unfortunately. Contributions through our code review system at https://codereview.qt-project.org are always welcome. See https://codereview.qt-project.org/q/project:qt-creator%252Felfutils for older changes, and please add me as a reviewer if you push something. cheers, Ulf
