[PATCH] D42021: [DWARF] v5 implementation of string offsets tables - producer side

[David Blaikie via llvm-commits]

On Thu, Jan 18, 2018 at 12:29 PM Paul Robinson via Phabricator <
reviews at reviews.llvm.org> wrote:

> probinson added inline comments.
>
>
> ================
> Comment at: test/DebugInfo/Generic/string-offsets-multiple-cus.ll:71-72
> +;
> +; Verify that the type unit has the proper DW_AT_str_offsets_base
> attribute and
> +; a segment in the .debug_str_offsets section.
> +;
> ----------------
> wolfgangp wrote:
> > dblaikie wrote:
> > > Is each type unit getting its own string offset? I'd expect type units
> to use the string offset table of the CU they were attached to, so this
> should be the same as CU1_STROFF?
> > >
> > > I mean it's a tradeoff - using separate string offset sections per TU
> means they can be dropped if this copy of the TU is dropped. But it also
> means more duplication - the same string offset having to be duplicated in
> the CU and every TU if the same string appears in all/several of them.
> > At the moment all the units in a compilation share the same string
> offsets table. I corrected all the xxx_STROFF lit variables. I'm not sure
> if it's really worth it to drop the string offsets that belong to a dropped
> unit. I would think the gain would be small.
> The thing is if we have a relocation from the string offsets to the
> string, and don't drop the entry in the offsets table, the linker can't
> drop the string, even if there are no actual references left.  That would
> be the significant savings.
>

If this unit is only dropped due to deduplication by the linker - the
strings will, presumably, still be needed by the remaining instance of the
type unit - so yeah, probably just the offsets that would be unnecessarily
kept.

- Dave


>
>
> https://reviews.llvm.org/D42021
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180121/c979302c/attachment.html>