[llvm-dev] Implementing a DWP tool in LLVM

Alexey Samsonov via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 3 17:06:01 PST 2015


SGTM. This will bring us closer to the point when we can write tests, where
we strip out the .dwo files from executables, package them together with
llvm-dwp, and then verify that we still get all we need from
llvm-symbolizer.

I didn't fully understand the part about walking DIEs to patch references
from .debug_info.dwo to .debug_loc.dwo: shouldn't their values stay the
same, as they will be treated relative to the value of DW_SECT_LOC offset?

On Tue, Nov 3, 2015 at 1:52 PM, David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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 ( https://gcc.gnu.org/wiki/DebugFissionDWP ) in LLVM.
>
> 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.
>
> 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.
>
> Likely I'll start with:
>
> * adding llvm-dwarfdump support for the DWP indexes
> * basic prototype of llvm-dwp just concatenating sections
> * handle each of the domain specific relocations in turn
>   * abbr_offset
>   * debug_str_offsets.dwo entries
>   * type_unit's DW_AT_stmt_list
>   * references to debug_loc.dwo from debug_info.dwo
>      * 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)
> * deduplicate type units
> * add CU/TU indexes
> * DWP merging (being able to read existing indexes and merge those into
> larger indexes)
> * possibly support the thin DWP mode
>
> Does this all seem feasible/plausible/reasonable to do in LLVM? Any
> particular points of contention/interest/clarification?
>
> 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).
>
> - Dave
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/1c0ab6e3/attachment.html>


More information about the llvm-dev mailing list