llvm dev - Jan 2018 - Adding DWARF5 accelerator table support to llvm

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
>

> On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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, 
Some background for the benefit of everyone who may not be aware of the genesis
of the DWARF v5 accelerator tables:

DWARF v5 accelerator tables are a direct evolution of the "Apple"
accelerator tables that are implemented in LLVM (after going through the
standardization process and being reworked/generalized there), so we hope that
the implementation can at least share some common interfaces with the existing
Apple accelerator table implementation where this makes sense.

-- adrian

FWIW I'm completely on board with everything Adrian has said in this thread
:)

-eric

On Wed, Jan 17, 2018 at 11:00 AM Adrian Prantl via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> > On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > 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,
>
> Some background for the benefit of everyone who may not be aware of the
> genesis of the DWARF v5 accelerator tables:
>
> DWARF v5 accelerator tables are a direct evolution of the "Apple"
> accelerator tables that are implemented in LLVM (after going through the
> standardization process and being reworked/generalized there), so we hope
> that the implementation can at least share some common interfaces with the
> existing Apple accelerator table implementation where this makes sense.
>
> -- adrian
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180117/b2de61b6/attachment.html>