[Bug libdw/30948] src/stack doesn't show source inforamtion if the target is compiled with clang
https://sourceware.org/bugzilla/show_bug.cgi?id=30948 --- Comment #3 from Mark Wielaard --- See also https://sourceware.org/bugzilla/show_bug.cgi?id=22288 The issue is that we rely on .debug_aranges to know whether a (code) address is described in a particular DWARF CU (and from there which line table to use). We could create an aranges table ourselves, that means scanning over all the Compile Units and look at the first CU DIE, which will have a low-pc and high-pc (or ranges) attribute describing the addresses. The tricky bit is "merging" that with any existing .debug_aranges table. And that even if there is a .debug_aranges it might not be complete. So I think what we need to do is whenever we try to match up an address to a CU, we first check the .debug_aranges, if it doesn't match (and it is the first time) we do a full scan over all CUs and create or auxilary aranges table, then use that for (any future) mapping. I think this needs to be done in dwarf_addrdie which uses dwarf_getaranges but we might have to look at other places which use dwarf_getaranges and decide whether to make that functions the "magic" one or if that will always report the actual .debug_aranges. I think I would prefer if dwarf_getaranges would remain reporting the actual .debug_aranges data (if it is there). -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH 13/14] libdw: Apply DWARF package file section offsets where appropriate
On Thu, Nov 02, 2023 at 11:20:33PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Wed, Sep 27, 2023 at 11:21:02AM -0700, Omar Sandoval wrote:
> > The final piece of DWARF package file support is that offsets have to be
> > interpreted relative to the section offset from the package index.
> > .debug_abbrev.dwo is already covered, so sprinkle around calls to
> > dwarf_cu_dwp_section_info for the remaining sections: .debug_line.dwo,
> > .debug_loclists.dwo/.debug_loc.dwo, .debug_str_offsets.dwo,
> > .debug_macro.dwo/.debug_macinfo.dwo, and .debug_rnglists.dwo. With all
> > of that in place, we can finally test various libdw functions on dwp
> > files.
>
> This looks good, but obviously needs some earlier patches.
[snip]
> > @@ -1222,18 +1223,22 @@ __libdw_cu_ranges_base (Dwarf_CU *cu)
> > }
> >else
> > {
> > + Dwarf_Off dwp_offset = 0;
> > + dwarf_cu_dwp_section_info (cu, DW_SECT_RNGLISTS, &dwp_offset, NULL);
>
> Shouldn't we check there wasn't an error?
Yeah, I was a little confused by the error handling in these foo_base
functions. It doesn't seem like most of the callers are checking for
errors. The foo_base functions also seem to be treating invalid
attributes as if they don't exist (e.g., when dwarf_formudata returns an
error):
if (dwarf_attr (&cu_die, DW_AT_rnglists_base, &attr) != NULL)
{
Dwarf_Word off;
if (dwarf_formudata (&attr, &off) == 0)
offset += off;
}
So I suppose the equivalent for this change would be
Dwarf_Off dwp_offset = 0;
if (dwarf_cu_dwp_section_info (cu, DW_SECT_RNGLISTS, &dwp_offset, NULL) == 0)
offset = dwp_offset;
[snip]
Thanks!
Re: [PATCH 00/14] elfutils: DWARF package (.dwp) file support
On Fri, Nov 03, 2023 at 12:05:57AM +0100, Mark Wielaard wrote: > Hi Omar, > > On Wed, Sep 27, 2023 at 11:20:49AM -0700, Omar Sandoval wrote: > > This patch series adds support for DWARF package files to libdw and the > > elfutils tools. It supports the GNU DebugFission format for DWARF 4 [1] > > and the format standardized in DWARF 5 (section 7.3.5 "DWARF Package > > Files"). It supports both automatically opening the .dwp file for a > > skeleton unit and examining the .dwp file alone, just like for .dwo > > files. > > I had hoped to review and apply all this for the 0.190 release > tomorrow, but wasn't fast enough. No problem, I'll be happy to see it in 0.191 instead. > In general it looks very good and > most has been applied as is. Except for the last patch I don't have > real concerns, just a few questions (see the specific reviews). > > > Patch 1 is a trivial cleanup I found while developing this. Patches 2-6 > > are fixes for unrelated bugs in split DWARF and/or DWARF 5 that I > > encountered while adding test cases for this series. > > These have all been applied some time ago. > > > The actual dwp support is in patches 7-10 and 13, including test cases. > > 7 and 9 have been applied already. 8 has some comments/nitpicks, I can > probably easily be convinced to accept it. 10 looks good, but depends > on 8, some questions, specificly about handling split type units. 13 > looks good, but depends on 8 and 10. I replied to patch 8 with how drgn wants to use the new interface. I also replied with a couple of questions about how you'd like me to split up patch 8 and handle errors in a couple of the existing codepaths. > > Patches 11 and 12 enable testing macro information in dwp files. > > Both applied. > > > Patch 14 adds support and tests for an LLVM extension to the dwp > > format. > > I have to think a bit more on this. Yeah, the whole situation is very unfortunate. I tried to keep the workaround as unintrusive as possible, so it wouldn't be the end of the world if we had to carry our own patch for it. Of course, since LLVM supports it upstream, I'd definitely prefer for elfutils to support it upstream, too. I'll rebase my remaining patches and address the comments so far while I wait for your responses. Thanks!
[Bug libdw/30967] Discriminator in Dwarf_Line_s may exceed 24 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=30967 --- Comment #14 from Aleksei Vetrov --- Here are investigation results on why this happens in LLVM. It is a new algorithm for assigning "hierarchical discriminator for FSAFDO". >From https://reviews.llvm.org/D102246: #define BASE_DIS_BIT_BEG 0 #define BASE_DIS_BIT_END 7 #define PASS_1_DIS_BIT_BEG 8 #define PASS_1_DIS_BIT_END 13 #define PASS_2_DIS_BIT_BEG 14 #define PASS_2_DIS_BIT_END 19 #define PASS_3_DIS_BIT_BEG 20 #define PASS_3_DIS_BIT_END 25 #define PASS_LAST_DIS_BIT_BEG 26 #define PASS_LAST_DIS_BIT_END 31 unsigned DiscriminatorCurrPass; DiscriminatorCurrPass = R.second ? ++LDCM[LD] : LDCM[LD]; DiscriminatorCurrPass = DiscriminatorCurrPass << LowBit; // LowBit is 26, this guarantees a big discriminator ^ DiscriminatorCurrPass += getCallStackHash(BB, I, DIL); DiscriminatorCurrPass &= BitMaskThisPass; unsigned NewD = Discriminator | DiscriminatorCurrPass; const auto *const NewDIL = DIL->cloneWithDiscriminator(NewD); FS discriminator seems to deliberately use bit 26-31 to add fields for its pass. So this big discriminator is caused by `-enable-fs-discriminator=true`. The good news is this will not increase discriminators to bigger than UINT_MAX. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30967] Discriminator in Dwarf_Line_s may exceed 24 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=30967 --- Comment #15 from Aleksei Vetrov --- Created attachment 15213 --> https://sourceware.org/bugzilla/attachment.cgi?id=15213&action=edit logger_write.cpp Attaching "logger_write.cpp" and a way to reproduce binary with big discriminator with clang-16: ``` clang++-16 -c -std=gnu++17 -O2 -g -nostdlibinc -m32 -march=prescott -fPIC \ -fdebug-info-for-profiling -funique-internal-linkage-names -mllvm \ -enable-fs-discriminator=true -o logger_write.o logger_write.cpp ``` And the output of `llvm-dwarfdump --debug-line logger_write.o` should show something like this: ``` 0x00b3 5127 0 01207968256 0x00bb 5127 0 01207968257 0x00bf 5144 0 01207968258 ``` -- You are receiving this mail because: You are on the CC list for the bug.
