[llvm-dev] [lldb-dev] Adding DWARF5 accelerator table support to llvm

Greg Clayton via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 17 10:22:50 PST 2018

> On Jan 17, 2018, at 8:13 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> Hello all,
> In <https://reviews.llvm.org/D41986#977215> it was brought up that
> there are at least two parties interested in having DWARF5 accelerator
> tables implemented, so I'm writing this email to see if there's anyone
> else interested in this topic, and to try to synchronize our efforts.
> Our interest for this stems from a desire to make dwarf parsing fast
> on non-apple targets (specifically android). As you may know, apple
> targets already use a non-standard accelerator table format, which was
> a precursor to the dwarf5 one. Due to other differences in debug info
> deployment model, the apple tables are not directly applicable to
> other targets, so instead of trying to make them fit, we chose to go
> with the standard approach.
> I personally will have some time to work on this this quarter or two,
> and my plan is roughly the following:
> 1. add .debug_names support to llvm-dwarfdump via the DebugInfo
> library (to enable testing of the table generation)
> 2. add .debug_names generation support (not enabled by default)
> 3. add .debug_names support to lldb
> 4. validate all three things work together
> 5. hook up .debug_names to clang's -glldb flag.
> 6. add .debug_names support to lld (accelerator table merging)
> Right now I have (1) roughly implemented, and I think I'll be able to
> put it up for review in a couple of days (although I expect the review
> will go through several revisions before being accepted). I also have
> a very basic implementation of (2), but this is still quite far from
> being upstreamable.
> So, my question is whether anyone is planning to work, or maybe
> working already on dwarf5 accelerator tables? Help with reviewing
> patches would also be greatly appreciated. If you have any questions
> or concerns, let me know.

This sounds great. I would also vote for a few additions to the work:
- modify llvm-dwarfdump or llvm-dsymutil to be able to compute and add the Apple and DWARF accelerator tables to existing object files that have DWARF in them. As we are working out the bugs we might end up with compiler bugs where not everything was added to the accelerator tables that was required. llvm-dsymutil has a "--update" option that allows it to update and re-create the Apple accelerator tables in a dSYM file. It would be nice to have this functionality so that when we pull legacy DWARF files from a build server, we have a simple way to update them with the needed indexing info so we can debug them as quickly as new DWARF files.

Within LLDB, the DWARF parser will need to abstract the indexing lookups. Right now we have each function that accesses the index doing:

  if (m_using_apple_tables) {
    if (m_apple_types_ap.get()) {
      const char *name_cstr = name.GetCString();
      m_apple_types_ap->FindByName(name_cstr, die_offsets);
  } else {
    if (!m_indexed)

    m_type_index.Find(name, die_offsets);

We should abstract these out into a indexing base class and have one for manual DWARF indexing, one for Apple accelerator table and one for .debug_names. I look forward to seeing this in LLDB!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180117/4f4650d3/attachment.html>

More information about the llvm-dev mailing list