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

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
mean, you could identify which CU points to that line table header, 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/010a9809/attachment.html>

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>

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.

No, I meant line table header… what you're saying is all fine for dumping a
str_offsets section, or resolving a strx form in a CU, but I'm trying to
resolve a strx in a line-table header in a DWO.  Maybe that wasn't clear,
but that's where I'm headed.
--paulr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/a3b7db87/attachment.html>