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

[Jonas Devlieghere via llvm-dev]

Hi Pavel,

As mentioned by Adrian in the comment you linked, I too am looking at DWARFv5
accelerator tables in LLVM. 

To give you some background: my motivation is that I want to upstream support
for (Apple style) accelerator tables in llvm-dsymutil, which is currently
missing because the way they are generated is slightly different. As this
requires making changes the current code, I wanted to consider the impact on
the standard's tables. I have some old patches from Fred (Riss) that take different
approaches to this, but I have nothing concrete yet for the v5 part.

Ultimately my goal is to share as much logic as possible between the Apple and
DWARFv5 implementations, both on the reading and generation side of things.

Your timeline seems sensible. Adding support in llvm-dwarfdump will be very
useful. I look forward to reviewing this. 

How do you feel about creating a [WIP] diff for (2). I'm very excited about
bundling our efforts on this. Let me know what I can do if there's anything
else I can help with. 

Cheers,
Jonas

> On 17 Jan 2018, at 16:40, Victor Leschuk <vleschuk at accesssoftek.com> wrote:
> 
> Hello, I hope I will have time to help you with that. I discussed
> dwarfv5 .debug_names implementation with involved party from RH. Anyway
> even if can't help much could you keep me in the loop please?
> 
> 
> On 01/17/2018 07:13 PM, Pavel Labath via llvm-dev 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.
>> 
>> regards,
>> Pavel
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> -- 
> Best Regards,
> 
> Victor Leschuk | Software Engineer | Access Softek
>