similar to: Adding DWARF5 accelerator table support to llvm

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

On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: > so I'm writing this email to see if there's anyone > else interested in this topic, and to try to synchronize our efforts. I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer for GDB (but not producing/using DW_IDX_DIE_offset as GDB cannot use it). > 1. add .debug_names support to

Hello again, It's been nearly six months since my first email, so it's a good time to recap what has been done here so far. I am happy to report that stages 1-3 (i.e. producer/consumer in llvm and integration with lldb) of my original plan are now complete with one caveat. The caveat is that the .debug_names section is presently not a full drop-in replacement for the .apple_*** sections.

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

> On Jan 30, 2018, at 7:35 AM, Pavel Labath <labath at google.com> wrote: > > Hello all, > > I am looking for feedback regarding implementation of the case folding > algorithm for .debug_names hashes. > > Unlike the apple tables, the .debug_names hashes are computed from > case-folded names (to enable case-insensitive lookups for languages > where that makes

> On Jun 13, 2018, at 11:18 AM, Jonas Devlieghere via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Hi Pavel, > >> On Jun 13, 2018, at 6:56 AM, Pavel Labath <labath at google.com <mailto:labath at google.com>> wrote: >> >> Hello again, >> >> It's been nearly six months since my first email, so it's a good time >> to

Hello all, I am looking for feedback regarding implementation of the case folding algorithm for .debug_names hashes. Unlike the apple tables, the .debug_names hashes are computed from case-folded names (to enable case-insensitive lookups for languages where that makes sense). The dwarf5 document specifies that the case folding should be done according the the "Caseless matching"

> On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thank you all. I am going to try to reply to all comments in a single email. > > Regarding the .apple_objc idea, I am afraid the situation is not as > simple as just flipping a switch. Jonas is currently working on adding the support for DWARF5-style Objective-C accelerator

On 30 January 2018 at 15:41, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Jan 30, 2018, at 7:35 AM, Pavel Labath <labath at google.com> wrote: >> >> Hello all, >> >> I am looking for feedback regarding implementation of the case folding >> algorithm for .debug_names hashes. >> >> Unlike the apple tables, the .debug_names

> On Jan 18, 2018, at 7:52 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Thank you for all the responses. Unfortunately I wasn't able to make > any progress on creating the patches today. I'll be sure to add > everyone who expressed interest here to the phabricator diff once I > have them ready. > > Jonas, do you have any dsymutil

On 30 January 2018 at 16:39, Jan Kratochvil <jan.kratochvil at redhat.com> wrote: > On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: >> so I'm writing this email to see if there's anyone >> else interested in this topic, and to try to synchronize our efforts. > > I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer >

On Thu, 14 Jun 2018 at 19:26, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath <labath at google.com> wrote: >> >> On Thu, 14 Jun 2018 at 17:58, Greg Clayton <clayborg at gmail.com> wrote: >> > >> > >> > >> > On Jun 14, 2018, at 9:36 AM, Adrian Prantl <aprantl at

On Thu, 14 Jun 2018 at 17:58, Greg Clayton <clayborg at gmail.com> wrote: > > > > On Jun 14, 2018, at 9:36 AM, Adrian Prantl <aprantl at apple.com> wrote: > > > > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thank you all. I am going to try to reply to all comments in a single email. > >

oh, awesome. Were you using type units? (I imagine that'd make the situation worse - since the way clang emits DWARF for a type with a member function template implicit specialization is to emit the type unit without any mention of this, and to emit the implicit specialization declaration into the stub type in the CU (that references the type unit)) Without type units I'd be pretty

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

Thank you for all the responses. Unfortunately I wasn't able to make any progress on creating the patches today. I'll be sure to add everyone who expressed interest here to the phabricator diff once I have them ready. Jonas, do you have any dsymutil patches I can look at? I am interested in seeing what kind of interfaces are you using, particularly on the reading side. I think the current

Hi llvm-dev, cfe-dev, It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention-- 1. Language aspects 2. Location mostly optimized out ones 3. DebugInfo conformance to DWARF-5 To avoid getting conflicted with some body

How do you handle name lookup for nested classes? They have the same problem (they don't appear in all definitions) - don't appear in all descriptions of the outer/parent class. (in theory we could ensure there's always at least a declaration of the nested class - but we don't even do that if the nested class is unused) Is it just the case that Clang doesn't mind you adding a

> On Jun 15, 2018, at 9:23 AM, <paul.robinson at sony.com> <paul.robinson at sony.com> wrote: > >> From: Greg Clayton [mailto:clayborg at gmail.com] >> >> ... >> If a class has templated functions, they will only be in the DWARF is a >> specialization was created and used. If you have a class that looks like: >> >> class A { >>

r330121 should fix that. Let me know if you still run into any issues. cheers, pl On Mon, 16 Apr 2018 at 12:07, Pavel Labath <labath at google.com> wrote: > Hello Csaba, > Thanks for the heads up. I am the one who wrote that test. I'll look into > that shortly. Sorry about the trouble. > pl > On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < > llvm-dev at