search for: dwarf5

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...

...ty 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)....

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" Section of the Unicode standard (whose implementation is basically a long list of special cases). While certainly possible, implementing this would be much more complicated (and would probably ma...

...em 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 DWARFAcceleratorTable interface will > need to be redesigned a bit if we want it to fit the dwarf5 tables as > well. Dsymutil never reads accelerator tables. It rebuilds them while walking the debug_info section. Fred > On 17 January 2018 at 20:52, Eric Christopher via lldb-dev > <lldb-dev at lists.llvm.org> wrote: >> FWIW I'm completely on board with everything Adria...

...r 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" Section >> of the Unicode standard (whose implementation is basically a long list >> of special cases). While certainly possible, implementing this would >> be much mor...

...gt; 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" Section > of the Unicode standard (whose implementation is basically a long list > of special cases). While certainly possible, implementing this would > be much more complicated (a...

...39;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 (s...

...cator 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 DWARFAcceleratorTable interface will need to be redesigned a bit if we want it to fit the dwarf5 tables as well. On 17 January 2018 at 20:52, Eric Christopher via lldb-dev <lldb-dev at lists.llvm.org> wrote: > 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 &g...

...bvious) that optimization can be useful. Though -fdebug-types-section is disabled by default. Looks it was initially disabled because not all of DWARF consumers were aware of .debug_types section. Now in 2017 situation is different. I think most of DWARF consumers knows about .debug_types, but: 1) DWARF5 specification explicitly eliminates the .debug_types section introduced in DWARF4: p8, "1.4 Changes from Version 4 to Version 5" http://dwarfstd.org/doc/DWARF5.pdf 2) Instead of emiting multiple .debug_types it suggests to emit multiple .debug_info COMDAT sections. (p375, p376). An...

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

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 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

Hi DebugInfo folks, I have a question on using fsplit-dwarf-inlining option: "-fsplit-dwarf-inlining, -fno-split-dwarf-inlining Provide minimal debug info in the object/executable to facilitate online symbolication/stack traces in the absence of .dwo/.dwp files when using Split DWARF" i.e. it puts some debug info into compilation unit from First partition(with Skeleton unit). 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 tables to LLVM/LLDB/dsymutil. Based on the assumption that DWARF 4 and earlier are unaffected by any of this, I don't think it's necessary to spend any effort of making the transition smooth. I'm fine with having Objective-C on DWARF 5 broken on trunk for t...

...it should ideally work with sections as pieces and should not know about content. That is not always possible, for example we have to look inside .eh_frame to deuplicate FDEs, but that is probably what we would want to avoid in general. >It doesn't seem especially important to implement the DWARF5 types -> debug_info thing for this situation, the type units >as they are (in debug_types) offer the same size benefits here. But sure, if anyone wanted to implement it at some point, that'd be fine. But there is no .debug_types in DWARF5, so it is depricated approach as far I understand...

...bvious) that optimization can be useful. Though -fdebug-types-section is disabled by default. Looks it was initially disabled because not all of DWARF consumers were aware of .debug_types section. Now in 2017 situation is different. I think most of DWARF consumers knows about .debug_types, but: 1) DWARF5 specification explicitly eliminates the .debug_types section introduced in DWARF4: p8, "1.4 Changes from Version 4 to Version 5" http://dwarfstd.org/doc/DWARF5.pdf 2) Instead of emiting multiple .debug_types it suggests to emit multiple .debug_info COMDAT sections. (p375, p376). An...

...to say valid vs garbage ranges(D59553). To resolve these two problems, we use implementation extracted from dsymutil https://reviews.llvm.org/D74169. It adds --gc-debuginfo command line option to the linker to remove obsolete debug info. Currently, it has the following limitations: does not support DWARF5, modules, -fdebug-types-section, type units, .debug_types, multiple .debug_info sections, split DWARF, thin lto. Following are size/performance results for the D74169: A: --function-sections --gc-sections B: --function-sections --gc-sections --gc-debuginfo C: --function-sections --gc-sections --f...

...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 tables to LLVM/LLDB/dsymutil. Based on the assumption that DWARF 4 and earlier are unaffected by any of this, I don't think it's necessary to spend any effort of making the transition smooth. I'm fine with having Objective-C on DWARF 5 broken on trunk for t...

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

...es-section is disabled by default. > > Looks it was initially disabled because not all of DWARF consumers were > > aware of .debug_types section. > > > > Now in 2017 situation is different. I think most of DWARF consumers knows > > about .debug_types, but: > > 1) DWARF5 specification explicitly eliminates the .debug_types section > > introduced in DWARF4: > > p8, "1.4 Changes from Version 4 to Version 5" > http://dwarfstd.org/doc/ > > DWARF5.pdf > > 2) Instead of emiting multiple .debug_types it suggests to emit multiple &gt...