<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 4, 2015 at 5:19 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> On Nov 3, 2015, at 1:52 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
> Much like the recent efforts to provide a port of dsymutil in the LLVM project, I'm looking at providing an implementation of the Fission/Split DWARF DWP tool ( <a href="https://gcc.gnu.org/wiki/DebugFissionDWP" rel="noreferrer" target="_blank">https://gcc.gnu.org/wiki/DebugFissionDWP</a> ) in LLVM.<br>
<br>
</span>Sound good!<br>
<span class=""><br>
> While there's potentially some overlap between the two tools, I'm thinking of keeping them separate at least initially since much of the debug info doesn't need to be touched by a DWP tool, unlike dsymutil.<br>
<br>
</span>While dsymutil and dwp appear to be similar on the surface, the actual functional overlap isn’t all that great. We should definitely look at opportunities to extract common code between the two, but developing them as separate tools makes total sense to me.<br></blockquote><div><br></div><div>Yeah, once we/someone starts wanting to do type merging in DWP, then it'll be interesting - until then, the DWP tool won't need to actually parse debug info or much of anything, really - except just a tiny bit of the first DIE in compile units, to get the hash. (speaking of - re: bag of dwarf, perhaps all units should be able to have a hash->offset mapping, then CUs in DWOs could have a hash->offset (where the offset would be 0, the first DIE) for their CU, so we could get the CU hash without parsing any DWARF)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> Basically all the tool needs to do is concatenate (or deduplicate, in the case of type units) the sections and apply a few domain-specific relocations, but that doesn't include having to read the DIE tree in debug_info.dwo (only the headers). The other thing is to build a couple of indexing data structures to allow fast lookup of CUs and TUs.<br>
><br>
> Likely I'll start with:<br>
><br>
> * adding llvm-dwarfdump support for the DWP indexes<br>
> * basic prototype of llvm-dwp just concatenating sections<br>
> * handle each of the domain specific relocations in turn<br>
>   * abbr_offset<br>
>   * debug_str_offsets.dwo entries<br>
>   * type_unit's DW_AT_stmt_list<br>
>   * references to debug_loc.dwo from debug_info.dwo<br>
>      * this one, at first blush, makes me particularly sad, as it'll involve actually walking all the DIEs in any CUs (stmt_list isn't great either, but at least that'd only be the header - same for accessing the signature for the CU, it's always in the root DIE)<br>
> * deduplicate type units<br>
> * add CU/TU indexes<br>
> * DWP merging (being able to read existing indexes and merge those into larger indexes)<br>
> * possibly support the thin DWP mode<br>
<br>
</span>What is thin DWP mode? (It’s not mentioned in the DWARF standard).<br></blockquote><div><br></div><div>Like a thin archive, as I understand it (it's described here: <a href="https://gcc.gnu.org/wiki/DebugFissionDWP">https://gcc.gnu.org/wiki/DebugFissionDWP</a> ) - indexes, but without actually merging all the stuff into a monolithic file.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
><br>
> Does this all seem feasible/plausible/reasonable to do in LLVM? Any particular points of contention/interest/clarification?<br>
<br>
</span>Sounds all quite reasonable. How are you going to build a test suite? Checking in binaries?<br></blockquote><div><br>Likely - can check in asm at least, if that's preferable (or at least check it in besides, potentially) - though DWARF in asm isn't a terribly legible format anyway.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> It's possible at some point in the future it might be nice to share the type merging logic of dsymutil (type units make sense when you don't have a debug aware linker - but they do have unfortunate overhead which would be nice to avoid, if possible), in which case there might be some code sharing opportunity. But the two tools are still going to be fairly different in their purpose/handling (dsymutil has to get the address mappings and update all of that, DWP won't  have to deal with code addresses, etc).<br>
<br>
</span>Agreed.<br>
<span class=""><font color="#888888">-- adrian</font></span></blockquote></div><br></div></div>