[Bug general/30241] New: RFE add APIs to elfutis libdw
https://sourceware.org/bugzilla/show_bug.cgi?id=30241 Bug ID: 30241 Summary: RFE add APIs to elfutis libdw Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: woodard at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Please add new APIs to write DWARF. Some of the users could be dwz and dyninst. One example would be: https://github.com/dyninst/dyninst/issues/1401#issuecomment-1473826160 where the problem is you relocate a function to instrument it but then the DWARF backtraces are then wrong. -- 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 Ben Woodard changed: What|Removed |Added CC||woodard at redhat dot com --- Comment #4 from Ben Woodard --- I think that keeping the default the same is fine but I think we should add an option to make it possible like the suggested "--dwarf=follow-links" and change the error to: "eu-readelf: cannot get debug context descriptor: No DWARF information found. Try: —dwarf=follow-links" -- 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 --- Comment #5 from Ben Woodard --- (In reply to Mark Wielaard from comment #3) > We could maybe add something like --dwarf=follow-links to eu-readelf. But > the DWARF information dumping is already somewhat different from the rest of > eu-readelf. The basic idea of eu-readelf is that you can dump headers, > segments and sections data. This is somewhat lower level than what you are > usually after when using DWARF. If you look at how eu-readelf dumps various > .debug sections you'll see that it really just dumps the data, and doesn't > use libdw at all. There are sometimes two ways to dump the section data > (--debug-dump=line and --debug-dump=decodedline), one which dumps the "raw" > data and one which uses libdw to decode the data first. So maybe we really > need a new tool to dump "decoded" DWARF, which isn't concerned with how the > DWARF data is precisely encoded, but just shows the information. For such a > tool (eu-dwarfdump ?) it would make perfect sense to follow, search and > download extra files when necessary. I really think that you need to reconsider this position. Take for example this situation. I'm trying to diagnose a problem with boost's DWARF that was reported to me by a dyninst developer. I want to: [ben@Mustang dwqual]$ export DEBUGINFOD_URLS=https://debuginfod.elfutils.org/ [ben@Mustang dwqual]$ export DEBUGINFOD_PROGRESS=1 [ben@Mustang dwqual]$ eu-readelf --debug-dump=loc /lib64/libboost_system.so.1.69.0 eu-readelf: cannot get debug context descriptor: No DWARF information found [ben@Mustang dwqual]$ rpm -qf /lib64/libboost_system.so.1.69.0 boost-system-1.69.0-18.fc32.x86_64 This could be a really a helpful debugging tool. We don't have to go digging around for the right debuginfo RPM for the distribution since it looks it up by buildid. I can just point eu-readelf and print out the DWARF for that binary which would work if we didn't do split dwarf. However, it doesn't work because we don't have a follow links function. This unnecessarily makes something that would be very useful, not useful simply because of ideological purity. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26696] New: Support SVE dwarf
https://sourceware.org/bugzilla/show_bug.cgi?id=26696 Bug ID: 26696 Summary: Support SVE dwarf Product: elfutils Version: unspecified Status: NEW Severity: enhancement Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: woodard at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- SVE is starting to appear on aarch64. There are a few enhancements needed within elfutils's DWARF support needed to support SVE. These changes are outlined here: https://static.docs.arm.com/100985//abi_sve_aadwarf_100985__00_en.pdf In particular it the Z registers aren't yet described in backends/aarch64_regs.c and neither is the Vector granule pseudo register. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/22252] Parallel parsing of CU's DIEs from libdw
https://sourceware.org/bugzilla/show_bug.cgi?id=22252 Ben Woodard changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ben Woodard --- Yea done. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26921] dwarf_getalt () not thread-safe
https://sourceware.org/bugzilla/show_bug.cgi?id=26921 Ben Woodard changed: What|Removed |Added CC||woodard at redhat dot com --- Comment #1 from Ben Woodard --- Created attachment 12982 --> https://sourceware.org/bugzilla/attachment.cgi?id=12982&action=edit example backtrace tsearch.c:243 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26921] dwarf_getalt () not thread-safe
https://sourceware.org/bugzilla/show_bug.cgi?id=26921 --- Comment #2 from Ben Woodard --- Created attachment 12983 --> https://sourceware.org/bugzilla/attachment.cgi?id=12983&action=edit example backtrace tsearch.c:229 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26921] dwarf_getalt () not thread-safe
https://sourceware.org/bugzilla/show_bug.cgi?id=26921 --- Comment #3 from Ben Woodard --- Created attachment 12984 --> https://sourceware.org/bugzilla/attachment.cgi?id=12984&action=edit example backtrace tsearch.c:269 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26921] dwarf_getalt () not thread-safe
https://sourceware.org/bugzilla/show_bug.cgi?id=26921 --- Comment #4 from Ben Woodard --- Created attachment 12985 --> https://sourceware.org/bugzilla/attachment.cgi?id=12985&action=edit example backtrace tsearch.c:214 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26921] dwarf_getalt () not thread-safe
https://sourceware.org/bugzilla/show_bug.cgi?id=26921 --- Comment #5 from Ben Woodard --- There were 214 crashes in my test that ended up in tseach.c those 4 back traces represent the 4 places where the problem occured. tsearch.c:229 - 181 cases tsearch.c:269 - 16 cases tsearch.c:214 - 13 cases tsearch.c:243 - 8 cases -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26921] dwarf_getalt () not thread-safe
https://sourceware.org/bugzilla/show_bug.cgi?id=26921 --- Comment #6 from Ben Woodard --- Created attachment 12986 --> https://sourceware.org/bugzilla/attachment.cgi?id=12986&action=edit a unique one at tsearch.c:229 This one particular crash is unique in that it does NOT contain __libdw_intern_next_unit -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/26921] dwarf_getalt () not thread-safe
https://sourceware.org/bugzilla/show_bug.cgi?id=26921 --- Comment #8 from Ben Woodard --- One thing that I’m unclear about is how these two are different. It doesn’t matter to me that they are split up but I just don’t understand why? -ben On Sat, Nov 21, 2020 at 2:00 PM mark at klomp dot org < sourceware-bugzi...@sourceware.org> wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=26921 > > --- Comment #7 from Mark Wielaard --- > Thanks for the backtraces, they show a different concurrent unsafe thing in > libdw, the usage of (lazy) tsearch caches. I opened a separate bug for > that, > bug #26930 > > -- > You are receiving this mail because: > You are on the CC list for the bug. > > -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28043] New: Add LSDA decoding to eu-readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=28043 Bug ID: 28043 Summary: Add LSDA decoding to eu-readelf Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: tools Assignee: unassigned at sourceware dot org Reporter: woodard at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- One thing that is an important aspect of compatibility between libraries and their consumers (apps and other libraries) are the exceptions thrown and caught. Ideally you want to make sure that all exceptions that could be thrown are properly caught Unfortunately it is currently EXTREMELY difficult to look at an ELF file see which exceptions are thrown or caught. That information is readily available in the ELF file it just isn't being decoded. This forces a user to manually interpret the ELF file and decode the LSDA by hand to list the types. This is very likely above the level of most developers. It would be nice if eu-readelf were able to decode the LSDA and print it in a human understandable form. I propose a feature that does this: eu-readelf --exceptions-thrown eu-readelf --exceptions-caught and maybe: eu-readelf --exceptions which effectively is the same as eu-readelf --exceptions-thrown --exceptions-caught So far the best descriptions of how to decode those sections that I have been able to find are: https://www.airs.com/blog/archives/464 and http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012-Skochinsky-Compiler-Internals.pdf (start at about page 35) The code that processes that section in GCC can be found in gcc/libgcc/unwind-c.c that could be a good reference. Once you have the LSDA decoding capabilities it may also be worthwhile to print out the decoded fields when doing --debug-dump=frame and pretty print the structures pointed to by the LSDA pointers. There is a possibility that at least at times llvm generates a different version of the LSDA and so for a fully functional tool you may also want to decode any flavors of LSDA that llvm may generate as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28043] Add LSDA decoding to eu-readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=28043 --- Comment #1 from Ben Woodard --- Having code or maybe even an API that decodes the LSDA would also be helpful for elfutils-libs users like libabigail as they work to resolve issues like: https://sourceware.org/bugzilla/show_bug.cgi?id=28025 -- You are receiving this mail because: You are on the CC list for the bug.
