[PATCH] D34765: [DWARF] [NFC] Move a couple of member functions to DWARFUnit (baseclass) from DWARFCompileUnit (derived class)

[Robinson, Paul via llvm-commits]

Just to finish this thought, DW_AT_str_offsets_base is spec'd to point to the first entry for the unit, not the header, so the first contribution is at 8 or 16 depending on format (picky picky).  That is, the entire section has only one header, rather than one header per compilation-unit or type-unit; you get one header + table per translation-unit.  (Too many kinds of unit!)  It seems not completely clear that it would be a net savings to maintain separate string pools (or string-offset pools) per unit, so I don't know whether you'd really want str_offsets_base in .dwo units.  Someone will have to run off and measure it at some point.
--paulr

From: llvm-commits [mailto:llvm-commits-bounces at lists.llvm.org] On Behalf Of David Blaikie via llvm-commits
Sent: Thursday, June 29, 2017 2:51 PM
To: reviews+D34765+public+e78f04ee01ee41e1 at reviews.llvm.org; Pieb, Wolfgang; aprantl at apple.com
Cc: llvm-commits at lists.llvm.org
Subject: Re: [PATCH] D34765: [DWARF] [NFC] Move a couple of member functions to DWARFUnit (baseclass) from DWARFCompileUnit (derived class)


On Thu, Jun 29, 2017 at 11:48 AM Paul Robinson via Phabricator <reviews at reviews.llvm.org<mailto:reviews at reviews.llvm.org>> wrote:
probinson added a comment.

In https://reviews.llvm.org/D34765#795601, @wolfgangp wrote:

> No you're right, my bad. Units in the .dwo sections (both type and CU) don't have a str_offsets_base, which implies that the .debug_str_offsets.dwo section has to consist of a monolithic table of string offsets (without the 8 or 16-byte header that's specified in section 7.26 of the DWARF 5 standard).  Section 7.26 seems to say the opposite, though. It seems I'll have to clarify this with the DWARF5 folks.


Worth clarifying on the dwarf-discuss list but I believe the idea is that the .dwo would have a single .debug_str_offsets.dwo contribution (complete with header), corresponding to the .debug_str.dwo contribution, and all units in the compilation would share it just like they would ordinarily share the single .debug_str section in a non-split compilation.

Yeah, seems to me like DWO CUs basically get a "DW_AT_str_off_base" (or whatever it's called) should be assumed/implicit 0, but can be present (if a producer wants to put multiple separate str_off for separate CUs in a single DWO - for example, to reduce the size of the str offsets (smaller numbers, shorter encoding, etc) in cases of many strings/many CUs, etc)



https://reviews.llvm.org/D34765


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170629/e1cbcf2b/attachment.html>