<div dir="ltr">Object order means quite a lot, but it usually is only important for the loadable data, as it has cache implications. This isn't an issue for debug data, as far as I understand it. Object order also has a number of other effects like what to do with COMDATs, weak symbol resolution, library inputs etc, but these are all link-time behaviour things, and once the right decisions (e.g. which input contributions to use) have been made, the linker could reorder the debug data as it wishes.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 11 Nov 2020 at 18:22, Robinson, Paul <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> -----Original Message-----<br>
> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of David<br>
> Blaikie via llvm-dev<br>
> Sent: Wednesday, November 11, 2020 12:46 PM<br>
> To: James Henderson <<a href="mailto:jh7370.2008@my.bristol.ac.uk" target="_blank">jh7370.2008@my.bristol.ac.uk</a>><br>
> Cc: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Subject: Re: [llvm-dev] [LLD] Support DWARF64, debug_info "sorting"<br>
> <br>
> On Wed, Nov 11, 2020 at 12:55 AM James Henderson<br>
> <<a href="mailto:jh7370.2008@my.bristol.ac.uk" target="_blank">jh7370.2008@my.bristol.ac.uk</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Wed, 11 Nov 2020 at 05:41, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> >><br>
> >> +James for context too (always good to include the folks from the<br>
> >> original threads for continuity)<br>
> >><br>
> >> Yeah, my general attitude there was just twofold, one that the<br>
> >> discussion had strayed fairly far from the review (so interested<br>
> >> parties might not see it, both because it's a targeted review thread<br>
> >> on the noisy llvm-commits, and because fo the title not having much<br>
> >> connection to the discussion) and it seemed to be somewhat<br>
> >> abstract/general - and there's a balance there. "We should do this<br>
> >> because I need it" (we shouldn't be implementing features for<br>
> >> especially niche use cases/if they don't generalize) isn't always a<br>
> >> compelling motivation but "we should do this because someone might<br>
> >> need it" isn't either (we shouldn't be implementing features that have<br>
> >> no users).<br>
> >><br>
> >> The major drawback in sorting, is the need to parse DWARF, even a<br>
> >> little bit of it (only the first 4 bytes of a section to tell which<br>
> >> version it is - first 12 if you want to be able to jump over<br>
> >> contributions and check /all/ contributions coming from a given input<br>
> >> object file (it might contain a combination of DWARFv4 and DWARFv5)<br>
> >> and then the hairy uncertainty of which sections to check (do you<br>
> >> check them all? well, all the ones with length prefixes that<br>
> >> communicate DWARF32/64 - some sections don't<br>
> >> (debug_ranges/loc/str/macro for instance, if I recall correctly)...<br>
> >> and if something has some 4 and 5, does it get sorted to the start? I<br>
> >> guess so.<br>
> >><br>
> > I assume this comment is meant to say DWARF32/DWARF64, not DWARFv4 and<br>
> DWARFv5, as the DWARF version (as opposed to the 32/64 bit style) is<br>
> irrelevant to this, I believe, at least for the current known DWARF<br>
> standards.<br>
> <br>
> Yep! thanks for the correction - had a lot of DWARFv4/v5 on my mind<br>
> due to other work, so got the terms jumbled up.<br>
> <br>
> >  Whilst the majority of objects will only have a single CU in them,<br>
> there will be exceptions (LTO-generated objects, -r merged objects etc),<br>
> so we do need to consider this approach. Mixtures would certainly be<br>
> possible, and there's no guarantee the CUs would be in a nice order with<br>
> 32-bit blocks before 64-bit blocks. If I follow this to its full<br>
> conclusion, you could potentially end up with a single .debug_info<br>
> (.debug_line, .debug_rnglists etc) input section with a mixture of<br>
> DWARF32/DWARF64 sub-sections, which, if following the reordering approach,<br>
> the linker might have to split up internally in order to rearrange (aside<br>
> - there's some interesting crossover with ideas I've been considering<br>
> regarding the Fragmented DWARF topic discussed elsewhere).<br>
> <br>
> I think given this is a pragmatic feature I'd be inclined to say "eh,<br>
> sort any input object containing at least one DWARFv4 contribution<br>
> before input objects not containing any v4 contribution" - if that<br>
> doesn't solve some real world issues/situations, I'd be willing to<br>
> revisit this direction/consider more invasive/expensive solutions.<br>
<br>
I was under the impression that *object* order meant a lot to people,<br>
and changing that would have all sorts of unpleasant fallout.  If I'm<br>
remember that correctly, sorting DWARF sections really should be its <br>
own thing, separate from object order.  Shoving DWARF-64 sections to<br>
the end of the line seems like it would be less problematic than <br>
reordering entire objects, if the linker can handle that in some<br>
reasonably efficient way.<br>
--paulr<br>
<br>
> <br>
> Though, as Eric said - some of this conversation might be better had<br>
> in terms of concrete patches with concrete performance measurements.<br>
> <br>
> > Maybe the solution here would be to change producers to produce separate<br>
> .debug_info sections containing DWARF32 and DWARF64.<br>
> <br>
> That'd involve changing how certain objects were generated - if that's<br>
> possible, then I assume it'd be possible to change that generation to<br>
> use DWARF64 anyway - in the limit: one might have precompiled binaries<br>
> with debug info that one cannot recompile, so any new format options I<br>
> doubt are able to address the original/likely use case for this<br>
> functionality.<br>
> <br>
> > I used the -u option more as an example that it might be possible to get<br>
> things to work the way we want without needing to have the linker do the<br>
> work. The linker currently has a --symbol-ordering-file option which can<br>
> be used to request an order for the specified list of symbols. The linker<br>
> does this by rearranging the input sections to get as close as it can to<br>
> the requested order. We could maybe implement the same on a file/section<br>
> basis. It would avoid needing to read the sections themselves, but doesn't<br>
> solve the "what to do about mixed single input" case directly (though<br>
> might allow the user to dodge the decision at least).<br>
> ><br>
> > Other ideas I had involved changing the section header properties.<br>
> Currently DWARF sections are all SHT_PROGBITS, but we could change that to<br>
> e.g. SHT_DWARF_32 or similar, and/or use the sh_info field to contain a<br>
> value that would indicate the 32/64 bit nature. I'm not convinced by these<br>
> ideas though, as a) I don't know if it translates well to other non-ELF<br>
> formats, and b) we can't really control the producers of DWARF at this<br>
> stage to conform.<br>
> ><br>
> > It would be nice if there was a solution that could be consistently<br>
> applied across all build systems, linkers and DWARF producers. I don't<br>
> have one as yet though.<br>
> ><br>
> >><br>
> >> On Tue, Nov 10, 2020 at 9:30 PM Eric Christopher via llvm-dev<br>
> >> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > On Wed, Nov 11, 2020 at 12:19 AM Alexander Yermolovich via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> >> >><br>
> >> >> This year Igor Kudrin put in a lot of work in enabling DWARF64<br>
> support in LLVM. At Facebook we are looking into it as one of the options<br>
> for handling debug information over 4gigs in production environment. One<br>
> concern is that due to mix of third party libraries and llvm compiled code<br>
> the final library/binary will have a mix of CU that are DWARF32/64. This<br>
> is supported by DWARF format. With this mix it is possible that even with<br>
> DWARF64 enabled one can still encounter relocation overflows errors in LLD<br>
> if DWARF32 sections happen to be processed towards the end.<br>
> >> >><br>
> >> >> One proposal that was discussed in<br>
> <a href="https://urldefense.com/v3/__https://reviews.llvm.org/D87011__;!!JmoZiZGBv3" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://reviews.llvm.org/D87011__;!!JmoZiZGBv3</a><br>
> RvKRSx!pnSYzjQly_yuEU-ng7OYd8nr3h3tSYOjeCwnH7cr3hA73rA8aVlNzOfQPo9Ue7WdoQ$<br>
> , is to modify LLD linker to arrange debug_info sections so that DWARF32<br>
> comes first, and DWARF64 after them. This way as long as DWARF32 sections<br>
> don't themselves go over 4gigs, the final binary can contain debug<br>
> information that exceeds 4gig. Which I think will be the common case.<br>
> >> >><br>
> >> >> An alternative approach that was proposed by James Henderson is for<br>
> build system to take care of it, and to use -u to enforce order.<br>
> >> ><br>
> >> ><br>
> >> > +Fangrui Song here for thread visibility<br>
> >> ><br>
> >> > Of these two approaches I think that the linker sorting is probably<br>
> the one I'd go with for the reasons you list below - I'm particularly<br>
> sympathetic to not wanting the unintended consequences of using -u here :)<br>
> >> ><br>
> >> > I do worry about slowing down general debug links so a "debug info<br>
> sorting" option may make sense, or it may not be worth it after measuring<br>
> the speed difference.<br>
> >> ><br>
> >> > Thanks for bringing this up on the list! :)<br>
> >> ><br>
> >> > -eric<br>
> >> ><br>
> >> >><br>
> >> >><br>
> >> >> As, I would imagine, most projects of scale are using configurable<br>
> build system that pulls in all the various dependencies automatically in a<br>
> multi-language environment. I think the alternative approach will be more<br>
> fragile than modifying LLD as it relies on a more complex system, and each<br>
> customer of LLD will have to implement this "sorting" in their own build<br>
> systems. The use of -u also kind of abuses this flag, and might have<br>
> unintended consequences. As was pointed out by Wen Lei.<br>
> >> >> From overhead perspective we only need to access few bytes of DWARF<br>
> to determine if it's 32 or 64 bits. Customers who need DWARF64, already<br>
> accept the overhead that it entails.<br>
> >> >><br>
> >> >> Any thoughts?<br>
> >> >><br>
> >> >> Thank You<br>
> >> >> Alex<br>
> >> >> _______________________________________________<br>
> >> >> LLVM Developers mailing list<br>
> >> >> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> >> >> <a href="https://urldefense.com/v3/__https://lists.llvm.org/cgi-" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.llvm.org/cgi-</a><br>
> bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!pnSYzjQly_yuEU-<br>
> ng7OYd8nr3h3tSYOjeCwnH7cr3hA73rA8aVlNzOfQPo9hAdGQGg$<br>
> >> ><br>
> >> > _______________________________________________<br>
> >> > LLVM Developers mailing list<br>
> >> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> >> > <a href="https://urldefense.com/v3/__https://lists.llvm.org/cgi-" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.llvm.org/cgi-</a><br>
> bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!pnSYzjQly_yuEU-<br>
> ng7OYd8nr3h3tSYOjeCwnH7cr3hA73rA8aVlNzOfQPo9hAdGQGg$<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://urldefense.com/v3/__https://lists.llvm.org/cgi-" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.llvm.org/cgi-</a><br>
> bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!pnSYzjQly_yuEU-<br>
> ng7OYd8nr3h3tSYOjeCwnH7cr3hA73rA8aVlNzOfQPo9hAdGQGg$<br>
</blockquote></div>