[Bug libdw/27805] New: libdwfl: Unable to extract source line information for RISC-V binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27805 Bug ID: 27805 Summary: libdwfl: Unable to extract source line information for RISC-V binary Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: n2knqf5ogu at bsogq dot anonbox.net CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13416 --> https://sourceware.org/bugzilla/attachment.cgi?id=13416&action=edit RV32IMC binary to reproduce the outlined issue For the attached RV32IMC (i.e. RISC-V) binary, libdwfl from elfutlis 0.183 is incapable of extracting source line information from provided DWARF debugging information. This can be easily reproduced by comparing the behavior of elfutils's addr2line with binutils's addr2line program. With binutils: $ addr2line --version GNU addr2line (GNU Binutils) 2.35.2 $ addr2line -e /tmp/elfutils-srcline-bug.elf 20400058 /home/john/src/RIOT/examples/hello-world/main.c:26 With elfutils: $ addr2line --version addr2line (elfutils) 0.183 $ addr2line -e /tmp/elfutils-srcline-bug.elf 20400058 ??:0 Briefly debugging this, it seems to me that dwfl_module_getsrc seems to return NULL and error out with DWARF_E_INVALID_OFFSET for this given binary. -- You are receiving this mail because: You are on the CC list for the bug.
Question
Hi, my name is John V. and I am seeking to use libelf. I notice from the Elfutils web page at sourceware.org/elfutils under the section entitled “License” that “The libraries and backends are dual GPLv2+/LGPLv3+.” Does this mean that I can pick and choose to use libelf under either the GPLv2+ or under LGPLv3+ and if so, how do I indicate which license I have chosen to use? I look forward to your reply. Thank you. John This email communication may contain CONFIDENTIAL INFORMATION WHICH ALSO MAY BE LEGALLY PRIVILEGED and is intended only for the use of the intended recipients identified above. If you are not the intended recipient of this communication, you are hereby notified that any unauthorized review, use, dissemination, distribution, downloading, or copying of this communication is strictly prohibited. If you are not the intended recipient and have received this communication in error, please immediately notify us by reply email, delete the communication and destroy all copies. GORDON REES SCULLY MANSUKHANI, LLP YOUR 50 STATE PARTNER® http://www.grsm.com
Re: Question
Hi - > Hi, my name is John V. and I am seeking to use libelf. Welcome. > I notice from the Elfutils web page at sourceware.org/elfutils under > the section entitled “License” that “The libraries and backends are > dual GPLv2+/LGPLv3+.” Yes. > Does this mean that I can pick and choose to use libelf under either > the GPLv2+ or under LGPLv3+ and if so, how do I indicate which > license I have chosen to use? The canonical answer is ... "ask your own lawyer". AIUI, the informal answer is: you choose. You don't have to make a statement about what you're doing. Sometimes people communicate it by removing one or the other license permission in a derived work. Or if e.g. an end user asks you for source code for a combined work, you need to do it under the rules for one or both. - FChE
Re: Storing package metadata in ELF objects
Hi, On Sat, 2021-04-10 at 18:44 +, Zbigniew Jędrzejewski-Szmek wrote: > [I'm forwarding the mail from Luca who is not subscribed to fedora- > devel] > On Sat, Apr 10, 2021 at 01:38:31PM +0100, Luca Boccassi wrote: > Cross-posting to the mailing lists of a few relevant projects. Note that in this version of the email the [N] references in your email don't seem to point anywhere. I found an older variant of the same email which contained: [0] https://github.com/systemd/systemd/issues/18433 [1] https://systemd.io/COREDUMP_PACKAGE_METADATA/ [2] https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects [3] https://github.com/systemd/package-notes > After an initial discussion [0], recently we have been working on a new > specification [0] to encode rich package-level metadata inside ELF > objects, so that it can be included automatically in generated coredump > files. The prototype to parse this in systemd-coredump and store the > information in systemd-journal is ready for testing and merged > upstream. We are now seeking further comments/opinions/suggestions, as > we have a few months before the next release and thus there's plenty of > time to make incompatible changes to the format and implementation, if > required. > > A proposal to use this by default for all packages built in Fedora 35 > has been submitted [1]. > > The Fedora Wiki and the systemd.io document have more details, but to > make a long story short, a new .notes.package section with a JSON > payload will be included in ELF objects, encoding various package- > build-time information like distro name&version, package > name&version, > etc. 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 > To summarize from the discussion, the main reasons why we believe this > is useful are as following: > > 1) minimal containers: the rpm database is not installed in the > containers. The information about build-ids needs to be stored > externally, so package name information is not available immediately, > but only after offline processing. The new note doesn't depend on the > rpm db in any way. > > 2) handling of a core from a container, where the container and host > have different distros > > 3) self-built and external packages: unless a lot of care is taken to > keep access to the debuginfo packages, this information may be lost. > The new note is available even if the repository metadata gets lost. > Users can easily provide equivalent information in a format that makes > sense in their own environment. It should work even when rpms and debs > and other formats are mixed, e.g. during container image creation. > > Other than in Fedora, we are already making the required code changes > at Microsoft to use the same format&specification for internally-built > binaries, and for tools that parse core files and logs. > > Tools for RPM and DEB (debhelper) integration are also available [3]. > > > -- > > Kind regards, > > Luca Boccassi > >
Re: Question
On Fri, 2021-04-30 at 13:06 -0400, Frank Ch. Eigler via Elfutils-devel wrote: > AIUI, the informal answer is: you choose. You don't have to make a > statement about what you're doing. Sometimes people communicate it by > removing one or the other license permission in a derived work. Or if > e.g. an end user asks you for source code for a combined work, you > need to do it under the rules for one or both. Yes, you don't actually have to choose, the simplest is to just redistribute under both, the actual license text says: This file is free software; you can redistribute it and/or modify it under the terms of either * the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version or * the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version or both in parallel, as here. Cheers, Mark
Re: [PATCH] RFC: come up with startswith function.
Hi Martin, On Wed, 2021-04-21 at 09:13 +0200, Martin Liška wrote: > Is the patch ready to be installed? Yes, it is. It looks good and makes the code simpler to read. Is it OK to add your Signed-off-by before I push it? See https://sourceware.org/git/?p=elfutils.git;a=blob_plain;f=CONTRIBUTING;hb=HEAD Thanks, Mark
Re: PATCH: PR27701: debuginfod clients with long-lived curl handles
Hi Frank, On Fri, Apr 23, 2021 at 03:43:09PM -0400, Frank Ch. Eigler via Elfutils-devel wrote: > PR27701: debuginfod client: encourage reused debuginfod_client objects > > Client objects now carry long-lived curl handles for outgoing > connections. This makes it more efficient for multiple sequential > queries, because the TCP connections and/or TLS state info are kept > around awhile, avoiding O(100ms) setup latencies. debuginfod is > adjusted to take advantage of this for federation. Other clients > should gradually do this too, perhaps including elfutils itself (in > the libdwfl->debuginfod_client hooks). > > A large gdb session with 117 debuginfo downloads was observed to run > twice as fast (45s vs. 1m30s wall-clock time), just in nuking this > extra setup latency. This was tested via a debuginfod intermediary: > it should be even faster once gdb reuses its own debuginfod_client. This is really nice. We should indeed also reuse a debuginfod_client handle in libdwfl for a Dwfl or Dwfl_Module when we figure out/document the multi-thread use case. The way debuginfod uses it is multi-thread safe since it makes sure only one thread at a time uses the same debuginfod_client handle. The code looks good. I have only two comments: > @@ -1095,6 +1087,11 @@ debuginfod_query_server (debuginfod_client *c, > > /* general purpose exit */ > out: > + /* Reset sent headers */ > + curl_slist_free_all (c->headers); > + c->headers = NULL; > + c->user_agent_set_p = 0; > + >/* Conclude the last \r status line */ >/* Another possibility is to use the ANSI CSI n K EL "Erase in Line" > code. That way, the previously printed messages would be erased, [...] > @@ -175,8 +177,8 @@ of the client object. > > .SS "HTTP HEADER" > > -Before a lookup function is initiated, a client application may > -add HTTP request headers to future downloads. > +Before each lookup function is initiated, a client application may > +add HTTP request headers. These are reset after each lookup function. Why do we need to reset the headers? Is that because we don't have debuginfod_remove_http_header? Should we maybe add that (or a reset_http_header)? > @@ -90,10 +113,6 @@ wait_ready() >done; > >if [ $timeout -eq 0 ]; then > - echo "metric $what never changed to $value on port $port" I think we want to keep this message ^ it helps with knowing which exact metric timed out. > - curl -s http://127.0.0.1:$port/metrics > - echo "logs for debuginfod with port $port" > - cat vlog$port > exit 1; >fi > } Cheers, Mark
Re: PATCH: PR27701: debuginfod clients with long-lived curl handles
Hi - > This is really nice. We should indeed also reuse a debuginfod_client > handle in libdwfl for a Dwfl or Dwfl_Module when we figure > out/document the multi-thread use case. [...] > > -Before a lookup function is initiated, a client application may > > -add HTTP request headers to future downloads. > > +Before each lookup function is initiated, a client application may > > +add HTTP request headers. These are reset after each lookup function. > > Why do we need to reset the headers? Is that because we don't have > debuginfod_remove_http_header? Should we maybe add that (or a > reset_http_header)? That would be possible too, probably, depending on how much state curl is willing to keep. Normal clients wouldn't do any of this. It's important for debuginfod's federated use case (proxying), which always resets between calls anyway. > > @@ -90,10 +113,6 @@ wait_ready() > >done; > > > >if [ $timeout -eq 0 ]; then > > - echo "metric $what never changed to $value on port $port" > > I think we want to keep this message ^ it helps with knowing which > exact metric timed out. OK. - FChE
