<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 29, 2017 at 12:42 PM Robinson, Paul <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-9191165330986943720WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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, </span></p></div></div></blockquote><div><br>I'm not sure how that would work in a non-fission, non-DWARF aware linker situation. Presumably each str_offsets section, with its header, would be concatenated together - so there would be one header per contribution, not one header for the whole section.<br><br>Equally, when merging DWO files into a DWP, if each DWO has offsets relative to its str_offsets contribution - then the whole contribution (including the header) must be taken from each DWO (otherwise the offsets would have to be rewritten, which would require parsing and modifying the DIEs, etc, which DWP avoids doing for performance & is the reason for str_offsets).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-9191165330986943720WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">rather than one header per compilation-unit or type-unit; you get one header + table per translation-unit. (Too many kinds of unit!)</span></p></div></div></blockquote><div><br>What distinction between compilation/type unit and translation unit are you making? DWARF doesn't, as far as I know, have a definition of Translation Unit (& I've always basically modeled it as C++ Translation Unit ~= DWARF Compilation Unit (& yeah, Type Units are a bit weird/out there, I think of them as not being owned by any particular Compilation Unit, etc))<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-9191165330986943720WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> 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.</span></p></div></div></blockquote><div><br>Oh, yeah, I'm not suggesting it'd totally be a win/necessary, just that it seems easy enough to leave it up to the implementation about how granular they get - allow a default for str_offsets_base (I'd be OK if there is no default) in Split DWARF, but let it be able to be specified (I think it'd fall out pretty naturally from consumers if it was specified anyway).<br><br>It's pretty awkward that the str_offsets_base points to the beginning of the table of strings, not the header... :/<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-9191165330986943720WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_-9191165330986943720__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-commits [mailto:<a href="mailto:llvm-commits-bounces@lists.llvm.org" target="_blank">llvm-commits-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>David Blaikie via llvm-commits<br>
<b>Sent:</b> Thursday, June 29, 2017 2:51 PM<br>
<b>To:</b> <a href="mailto:reviews%2BD34765%2Bpublic%2Be78f04ee01ee41e1@reviews.llvm.org" target="_blank">reviews+D34765+public+e78f04ee01ee41e1@reviews.llvm.org</a>; Pieb, Wolfgang; <a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a><br>
<b>Cc:</b> <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<b>Subject:</b> Re: [PATCH] D34765: [DWARF] [NFC] Move a couple of member functions to DWARFUnit (baseclass) from DWARFCompileUnit (derived class)<u></u><u></u></span></p>
</div>
</div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_-9191165330986943720WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Jun 29, 2017 at 11:48 AM Paul Robinson via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">probinson added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D34765#795601" target="_blank">https://reviews.llvm.org/D34765#795601</a>, @wolfgangp wrote:<br>
<br>
> 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.<br>
<br>
<br>
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.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<a href="https://reviews.llvm.org/D34765" target="_blank">https://reviews.llvm.org/D34765</a><br>
<br>
<br>
<u></u><u></u></p>
</blockquote>
</div>
</div>
</div></div></div></blockquote></div></div>