similar to: [LLD] Support DWARF64, debug_info "sorting"

+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 review thread on the noisy llvm-commits, and because fo the title not having much connection to the discussion)

This year Igor Kudrin put in a lot of work in enabling DWARF64 support in LLVM. At Facebook we are looking into it as one of the options for handling debug information over 4gigs in production environment. One concern is that due to mix of third party libraries and llvm compiled code the final library/binary will have a mix of CU that are DWARF32/64. This is supported by DWARF format. With this

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

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 will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > > all

On Wed, Nov 11, 2020 at 12:55 AM James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > > > 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

On 18.11.2020 0:20, Robinson, Paul wrote: > This is a problem only if the .debug_str section *by itself* exceeds 4GB; > are we anticipating that will happen IRL? The section is just a string > section, by itself it has no 32/64 format. > > 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

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

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David > Blaikie via llvm-dev > Sent: Wednesday, November 11, 2020 12:46 PM > To: James Henderson <jh7370.2008 at my.bristol.ac.uk> > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [LLD] Support DWARF64, debug_info "sorting" > > On Wed, Nov 11,

(Adding back Cc: which got dropped) > (Igor - I don't know what happened, but your email split the mail thread in gmail for me.) The problem is that https://lists.llvm.org/pipermail/llvm-dev/2020-November/146528.html does not have an In-Reply-To: header. Added Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer

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 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 2020-11-17, Igor Kudrin wrote: > >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 ->

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

In https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ (you need to join the group before making a post) Cary Coutant raised yet another idea: whether we can use ".debug64" as the section prefix. I like the idea because of: * It is immediately obvious whether DWARF64 is used and whether DWARF32 is used along with DWARF64. * In a relocatable link mixing DWARF32 and DWARF64 sections,

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. 🙂 Alex ________________________________ From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent:

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 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 will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > all input sections are SHT_DWARF64, the output section type probably > should also be SHT_DWARF64. > If mixed, SHT_PROGBITS. I am

On Fri, Nov 13, 2020 at 11:29 AM David Blaikie <dblaikie at gmail.com> wrote: > > 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: >

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

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