search for: debug_str_offset

...mon understanding of how it ought to work, and therefore what our code should do. For any non-DWARF-experts who might be interested, in principle this section is straightforward: It's an array of offsets into .debug_str, which in turn is a standard object-file string section. The idea behind .debug_str_offsets is that string references from other parts of the DWARF can use an index into the array, instead of a direct reference to the string section. This means we end up with only one object-file relocation per string, rather than one per reference. Fewer relocations = smaller object files and faster li...

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Pieb, > Wolfgang via llvm-dev > Sent: Wednesday, July 05, 2017 6:14 PM > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [DWARFv5] Reading the .debug_str_offsets section > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > > Robinson, Paul via llvm-dev > > Sent: Wednesday, July 05, 2017 1:35 PM > > To: llvm-dev at lists.llvm.org > > Subject: [llvm-dev] [DWARFv...

Yep, Wolfgang picked up on the one thing I saw too. This is why I like having people review my stuff. I think it's a bit of a pity that str_offsets_base can point into the middle of a str_offsets contribution in some ways Actually I changed my mind after saying that in the review, and in this writeup I concluded that it cannot do that. str_offsets_base points to the element immediately

...to build a couple of indexing data structures to allow fast lookup of CUs and TUs. Likely I'll start with: * adding llvm-dwarfdump support for the DWP indexes * basic prototype of llvm-dwp just concatenating sections * handle each of the domain specific relocations in turn * abbr_offset * debug_str_offsets.dwo entries * type_unit's DW_AT_stmt_list * references to debug_loc.dwo from debug_info.dwo * this one, at first blush, makes me particularly sad, as it'll involve actually walking all the DIEs in any CUs (stmt_list isn't great either, but at least that'd only be the heade...

...CUs and TUs. >> >> Likely I'll start with: >> >> * adding llvm-dwarfdump support for the DWP indexes >> * basic prototype of llvm-dwp just concatenating sections >> * handle each of the domain specific relocations in turn >> * abbr_offset >> * debug_str_offsets.dwo entries >> * type_unit's DW_AT_stmt_list >> * references to debug_loc.dwo from debug_info.dwo >> * this one, at first blush, makes me particularly sad, as it'll >> involve actually walking all the DIEs in any CUs (stmt_list isn't great >> eith...

...RM code, we now have whole new worlds of complication regarding where the actual string might be. We might have DW_FORM_strp which puts the actual string in the .debug_string section; eventually we could have DW_FORM_line_str (pointing to .debug_line_str) or even DW_FORM_strx (indirecting through .debug_str_offsets). Conveniently, we have the DWARFFormValue class which knows how to decode data based on what the form code is. Inconveniently, DWARFFormValue assumes it is looking at a .debug_info section, and picks up its relocations from a DWARFUnit. But if we're using DWARFFormValue to decode data from...

...mentioned (a) the difficulty of the detecting-DWARF64-by-first-relocation approach and (b) the section type approach in my reply there https://sourceware.org/pipermail/binutils/2020-November/114125.html (a) My prototype has made me feel uneasy with this approach. <quote> In DWARF v4 or if .debug_str_offset is not used, it is a problem. A heuristic is: if an input section in a file is marked DWARF64, we mark all other .debug_* DWARF64. This makes me feel a bit uneasy because for an output section description .debug_str 0 : { *(.debug_str) } Now the behavior of `*` (or, if we invent a `SORT_*` key...

...ation approach and (b) the section > > type approach in my reply there > > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > > > (a) My prototype has made me feel uneasy with this approach. > > > > <quote> > > In DWARF v4 or if .debug_str_offset is not used, it is a problem. A > > heuristic is: if an input section in a file is marked DWARF64, we mark > > all other .debug_* DWARF64. This makes me feel a bit uneasy because > > for an output section description > > > > .debug_str 0 : { *(.debug_str) } > &gt...

...t multiple DWO files stacked together - mostly to deduplicate strings and type units as a sort of archival (like dsym) format. The way DWPs work, roughly (full/more details here: https://gcc.gnu.org/wiki/DebugFissionDWP ) is that all the sections are concatenated together, except the debug_str and debug_str_offsets sections which have special handling to do what you'd expect - deduplicate strings, and adjust the str_offsets to point to the right offsets in the deduplicated string section. The other thing that DWP has, is an index, or two. cu_index and tu_index. We'll just look at cu_index. A cu_ind...

...t; detecting-DWARF64-by-first-relocation approach and (b) the section > type approach in my reply there > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > (a) My prototype has made me feel uneasy with this approach. > > <quote> > In DWARF v4 or if .debug_str_offset is not used, it is a problem. A > heuristic is: if an input section in a file is marked DWARF64, we mark > all other .debug_* DWARF64. This makes me feel a bit uneasy because > for an output section description > > .debug_str 0 : { *(.debug_str) } > > Now the behavior of `*`...

...gs and type units as a sort of archival (like dsym) format. >> >> The way DWPs work, roughly (full/more details here: https://gcc.gnu.org/wiki/DebugFissionDWP <https://gcc.gnu.org/wiki/DebugFissionDWP> ) is that all the sections are concatenated together, except the debug_str and debug_str_offsets sections which have special handling to do what you'd expect - deduplicate strings, and adjust the str_offsets to point to the right offsets in the deduplicated string section. >> >> The other thing that DWP has, is an index, or two. cu_index and tu_index. We'll just look at c...

...> > > type approach in my reply there > > > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > > > > > (a) My prototype has made me feel uneasy with this approach. > > > > > > <quote> > > > In DWARF v4 or if .debug_str_offset is not used, it is a problem. A > > > heuristic is: if an input section in a file is marked DWARF64, we mark > > > all other .debug_* DWARF64. This makes me feel a bit uneasy because > > > for an output section description > > > > > > .debug_str 0 : {...

...t multiple DWO files stacked together - mostly to deduplicate strings and type units as a sort of archival (like dsym) format. The way DWPs work, roughly (full/more details here: https://gcc.gnu.org/wiki/DebugFissionDWP ) is that all the sections are concatenated together, except the debug_str and debug_str_offsets sections which have special handling to do what you'd expect - deduplicate strings, and adjust the str_offsets to point to the right offsets in the deduplicated string section. The other thing that DWP has, is an index, or two. cu_index and tu_index. We'll just look at cu_index. A cu_ind...

...in my reply there > > > > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > > > > > > > (a) My prototype has made me feel uneasy with this approach. > > > > > > > > <quote> > > > > In DWARF v4 or if .debug_str_offset is not used, it is a problem. A > > > > heuristic is: if an input section in a file is marked DWARF64, we mark > > > > all other .debug_* DWARF64. This makes me feel a bit uneasy because > > > > for an output section description > > > > > > >...

...in my reply there > > > > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > > > > > > > (a) My prototype has made me feel uneasy with this approach. > > > > > > > > <quote> > > > > In DWARF v4 or if .debug_str_offset is not used, it is a problem. A > > > > heuristic is: if an input section in a file is marked DWARF64, we mark > > > > all other .debug_* DWARF64. This makes me feel a bit uneasy because > > > > for an output section description > > > > > > >...

..., .debug_rnglists, ...): * .debug_info: the first relocation references .debug_abbrev, good indicator * .debug_names references .debug_info: the first relocation (CU offset) is a good indicator * .debug_aranges references .debug_info: the first relocation (debug_info_offset) is a good indicator * .debug_str_offsets references .debug_str: the first relocation (.debug_str offset) is a good indicator * ... So checking the first relocation is probably sufficient. Even if we miss something, we can adjust the heuristic, or rather let the compiler generate an artificial relocation (R_*_NONE), which will always wor...

So Dehao and I have been dealing with some of the nitty gritty details of debug info with ThinLTO, specifically with Fission(Split DWARF). This applies to LTO as well, so I won't single out ThinLTO here. 1) Multiple CUs in a .dwo file Clang/LLVM produces a CU for each original source file - these CUs are kept through IR linking (thin or full) and produced as distinct CUs in the resulting

...pute the correct value. > > > > *nod* > > > > > That's the story for .debug_info; what about other sections? > > > > > > Sections referenced by index from .debug_info can't be fragmented; > > > this would be: .debug_abbrev, .debug_addr, .debug_str_offsets. > > > > > > .debug_str doesn't need to be fragmented, linkers DTRT already. > > > > (linkers deduplicate debug_str - but can they be made to remove > > unreferenced strings too? in that cas ewe'd have an interesting > > tradeoff of maybe using FOR...

> Thinking about it, I wouldn't expect an LTO generated object itself to have a mixture of DWARF32/64, although I guess the 32/64 bit state could be encoded in the IR (I am not familiar enough with it to know if it actually is or not). It might be necessary to find ways to configure LTO to generate DWARF64, possibly via a link-time option. I don’t think we need to encode dwarf32/64 in IR

...n with a reference to the bottom fragment should be able to > compute the correct value. *nod* > That's the story for .debug_info; what about other sections? > > Sections referenced by index from .debug_info can't be fragmented; > this would be: .debug_abbrev, .debug_addr, .debug_str_offsets. > > .debug_str doesn't need to be fragmented, linkers DTRT already. (linkers deduplicate debug_str - but can they be made to remove unreferenced strings too? in that cas ewe'd have an interesting tradeoff of maybe using FORM_strp rather than strx - if we wanted the linker to be abl...