[llvm-dev] [DWARFv5] Reading the .debug_str_offsets section

[David Blaikie via llvm-dev]

On Thu, Jul 6, 2017 at 11:59 AM Robinson, Paul <paul.robinson at sony.com>
wrote:

> 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 after the header.  You can have multiple units sharing
> the (entire) same contribution, but there's no slicing.
>
>
>
> 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.
>
>
>
> The trick with having multiple contributions in a DWO is that the
> .debug_line.dwo section has no way to specify which contribution to use.
>

I'd expect to use str_offsets_base in the DWO CU resolved relative to the
beginning of the DWO file, or relative to the beginning of the relevant
str_offsets contribution range in a DWP file. (& yeah, in the absence of
str_offsets_base, either the start of the contribution range (pre-standard
Fission), or the relevant start of range + size of header (standard form))


> I mean, you could identify which CU points to that line table header,
>

Guess that was str_offsets header - but if you're only dumping the
str_offsets you wouldn't need to know which CU points to it, and if you're
trying to resolve a str_index form in a CU, you know which CU you're in &
can use its str_offsets_base (+contribution range start), if present - same
as in non-DWO cases.

*shrug* no big deal, though. Just an orthogonality of features thing.


> and then find the contribution associated with that unit, but it seems
> less complicated to say the DWO has only one contribution and not have to
> bother with all that.
>
> I'm also not persuaded that having multiple str_offsets contributions in a
> normal .o file is all that helpful, or able to save space.  You save a
> byte, maybe two, per reference; but each unique string costs you 4, plus
> the header.  You can construct examples where it's a savings but in the
> general case I'm not so sure.
>
>
>
> Thanks,
>
> --paulr
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/34d56638/attachment.html>