[llvm-dev] [DWARFv5] Reading the .debug_str_offsets section
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 6 09:45:55 PDT 2017
Yep, Wolfgang picked up on the one thing I saw too.
Yeah, it's a pity some stuff (pre-standard split DWARF) doesn't have
headers to allow standalone decoding. (I assume there's a mandate on the
DWARF committee to have version headers for everything in every section
that can have them now (the only ones that can't that I can think of are
the actual string dedup sections because the linker actually looks at them
as strings, manipulates them, etc))
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 (because it means the
actual str offsets will be harder to read in that case "oh, string 5, that
means take the str_offsets_base address and add 5 * pointer size (which you
find by looking at the address range of the str_offsets_base)" - so if you
were dumping str_offsets you might print "header, string 1: "foo", string
2: "bar", etc... " - but now "string 5" might actually be "string 11"
because str_offsets_base is the start of string 6 (but it's not '6', its
the address... so you have to do all the decoding to figure that out) - a
dumper could do some of this so when it's dumping str_offsets_base it could
dump "0xdeadbeef, which is string 5 in the 3rd contribution"). Still,
that's a pretty unique form of cross-CU sharing that I've not seen
I think there'd be some point/benefit to being able to have multiple
contributions in a DWO file, but I don't think it's /buggy/ that it's not
allowed - just a possible future enhancement. "if you have a
str_offsets_base, great, otherwise it's assumed to be 0 + <header size> (or
just 0 if the CU uses GNU_dwo_id, rather than DWARF5 dwo_id, for example))
On Thu, Jul 6, 2017 at 6:35 AM Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > -----Original Message-----
> > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> > 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] [DWARFv5] Reading the .debug_str_offsets section
> > >
> > snip ...
> > >
> > > Things get way trickier in an object (executable or "-r" ouput) that
> > > has a mix of GCC and standard contributions. AFAICT there's no
> > > equivalent of DW_AT_str_offsets_base in the GCC style, so about all
> > > we can do is something like this:
> > > (1) Walk through all units to find all DW_AT_str_offsets_base pointers;
> > > (2) for each one, poke around in the prior 8-16 bytes looking for
> > > the header; this is more reliable than it sounds;
> > > (3) assume everything else in the section is GCC style.
> > I believe a mix of GCC and standard contributions should only be an issue
> > in a split-DWARF (fission) scenario, as there is no .debug_str_offsets
> > section in a non-split pre-V5 compilation AFAIK.
> Oh, of course! So a normal object file is always standard. Excellent!
> > And given that we don't have a DW_AT_str_offsets_base attribute in
> > .debug_info.dwo sections by standard decree, all units (whether standard
> > V5 or GCC-style) would have to share the single contribution in the
> > .debug_str_offsets.dwo section (or the single contribution in a slice of
> > the section via dwp index table).
> > So the only tricky part for the reader would be to figure out whether a
> > .debug_str_offsets.dwo section (or a slice of it) is GCC-style or a
> > (single) v5 standard contribution. As you pointed out earlier, either
> > looking at the individual unit versions in the .debug_info.dwo section or
> > the individual forms used could do the trick.
> > -- wolfgangp
> > > Questions and brickbats welcome.
> > > --paulr
> > >
> > > P.S. Ah, you clever reader, who noticed I carefully said nothing about
> > > LTO of mixed-DWARF-version compilations! Haven't thought about it.
> This is still a question. However I think it's not that hard to
> handle. If LTO sees a mix of v4 and v5, we emit a standard
> .debug_str_offsets.dwo section but force 32-bit offsets (i.e. leave
> a comment for our descendants to make sure that happens) and then
> the GCC forms will just DTRT. I think.
> The dumper would treat it as a standard section as long as there are
> any v5 units in the .dwo (or that contribution to the .dwp).
> IIRC the string sections aren't actually emitted until after all
> units have been processed, because everything shares the same string
> section, so remembering whether any v5 units have crossed our path
> and then adding the v5 header at the last moment should be feasible.
> > >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev