similar to: mirror for debug_info repo

Great, thanks! Those results are about roughly what I was expecting. I assume "compilation time" is actually just the link time? I find it particularly interesting that the DWARFLinker rewriting solution produces the same size improvement in .debug_line as the fragmented DWARF approach. That suggests that in that case, fragmented DWARF output is probably about as optimal as it can get.

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

> -----Original Message----- > From: Fāng-ruì Sòng <maskray at google.com> > Sent: Tuesday, November 17, 2020 1:51 AM > To: Alexander Yermolovich <ayermolo at fb.com> > Cc: David Blaikie <dblaikie at gmail.com>; Wenlei He <wenlei at fb.com>; llvm- > dev at lists.llvm.org; Robinson, Paul <paul.robinson at sony.com>; James > Henderson

Thinking about it, it would probably be wise to raise this discussion on the DWARF mailing list too. They might want to put an addendum in the spec/DWARF wiki/somewhere appropriate along the lines of "ELF support for DWARF64", which can be retroactively applied to existing standards. The committee may also have some thoughts on how tools are expected to work with DWARF64 and DWARF32

On 19.11.2020 03:21, Cary Coutant wrote: >>> If the .debug_str section *by itself* exceeds 4GB, then yes any string >>> with a 32-bit reference to it must be in the first 4GB. Strings that >>> have only 64-bit references to them can be sorted to the end of the >>> section, if necessary. I wouldn't think anyone guarantees or cares >>> about the

llvm[2]: Compiling DWARFDebugArangeSet.cpp for Debug+Asserts build llvm[2]: Compiling DWARFDebugAranges.cpp for Debug+Asserts build llvm[2]: Compiling DWARFDebugFrame.cpp for Debug+Asserts build /home/rkotler/llvm_trunk/lib/DebugInfo/DWARFDebugFrame.cpp:118:8: error: private field 'LinkedCIE' is not used [-Werror,-Wunused-private-field] CIE *LinkedCIE; ^ 1 error

Thanks for doing a diff and asking in other groups. So if I understand your concern with using first reloc as it relates to .debug_str. In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some .debug_info section we will have a relocation entry to patch up

On Fri, Nov 13, 2020 at 11:24 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > On Fri, Nov 13, 2020 at 11:17 AM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Fri, Nov 13, 2020 at 11:05 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > > > I got replies from Nick Clifton and Michael Matz: > > >

On Thu, Nov 12, 2020 at 4:43 PM Alexander Yermolovich <ayermolo at fb.com> wrote: > > Looks like there is an agreement that this path, modifying lld to order sections using relocations, should be explored. > If Igor doesn't object, since he was primary one driving DWARF64 so far, I would like to give it a shot at implementing and collecting some performance numbers. > >

On 2020-11-14, Alexander Yermolovich wrote: >Thanks for doing a diff and asking in other groups. > >So if I understand your concern with using first reloc as it relates to .debug_str. > >In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some

On Wed, Oct 9, 2013 at 5:22 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Wed, Oct 9, 2013 at 1:32 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> David, >> >> Thanks for reviewing! >> >> On Wed, Oct 9, 2013 at 11:36 AM, David Blaikie <dblaikie at gmail.com>wrote: >> >>> Might be easier if

That relocation handling is only done for the llvm-dwarfdump binary. MCJIT handles relocations a bit different. I think you just need to go ahead and allow the MCJIT relocation handling machinery to work on non-alloc sections and it should go ahead and handle these just fine, unless you're using the existing stuff in lib/DebugInfo to print out information or something? If this isn't what

> > If the .debug_str section *by itself* exceeds 4GB, then yes any string > > with a 32-bit reference to it must be in the first 4GB. Strings that > > have only 64-bit references to them can be sorted to the end of the > > section, if necessary. I wouldn't think anyone guarantees or cares > > about the order of strings within a string section. > > >

My concern with using section type, is that it does modify ELF format spec, and can break various tools that rely on this information. This sems somewhat of a heavy handed approach to solving this problem. Alternatively, if we do want to go with something more official then just doing it in a linker using first reloc, why not use sh_info? Seems like it's made for providing an extra

On Tue, Oct 15, 2013 at 10:10 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 10:05 AM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Wed, Oct 9, 2013 at 5:22 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >>> >>> >>> >>> On Wed, Oct 9, 2013 at

On Thu, May 28, 2015 at 4:36 PM, Alex <alexinbeijing at gmail.com> wrote: > Dear LLVM devs, > > I've noticed that LLVM's assembler (and hence clang) doesn't generate > debug data when assembling, even when run with "-g". > Sorry, let me correct that: the assembler does generate the .debug_info section (as well as line number data) when run with

On Wed, 11 Nov 2020 at 05:41, David Blaikie <dblaikie at gmail.com> wrote: > +James for context too (always good to include the folks from the > original threads for continuity) > > Yeah, my general attitude there was just twofold, one that the > discussion had strayed fairly far from the review (so interested > parties might not see it, both because it's a targeted

Thanks for feedback. I agree with patch and numbers this will be a more concrete discussion, but I wanted to judge overall receptiveness to this approach and see maybe there was a better way. "Whilst the majority of objects will only have a single CU in them, there will be exceptions (LTO-generated objects, -r merged objects etc), so we do need to consider this approach." David can you

On 17.11.2020 14:05, Fāng-ruì Sòng wrote: > On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: >> >> On 14.11.2020 3:42, Fāng-ruì Sòng wrote: >>> For .debug_* in object files: >>> >>> DWARF32 -> SHT_PROGBITS (unchanged) >>> DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 >>> >>> In LLD, we

I was thinking about whether I liked the section name idea myself. I think a slight refinement could be to have linkers combine .debug and .debug64 sections into one output section (in non -r links), so that end consumers (debuggers etc) don't have to worry about it. However, conformance is still a concern to me as we cannot really retrofit the existing standard versions, and the section names