[lld] r293963 - Update comments.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 6 14:18:50 PST 2017


I don't know much about the compatibility with BFD/gold since this part of
code was written mostly by Rafael and George. Maybe they can write about it?

On Fri, Feb 3, 2017 at 9:35 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> On Thu, Feb 2, 2017 at 3:26 PM, Rui Ueyama via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> Author: ruiu
>> Date: Thu Feb  2 17:26:12 2017
>> New Revision: 293963
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=293963&view=rev
>> Log:
>> Update comments.
>>
>> Modified:
>>     lld/trunk/ELF/LinkerScript.cpp
>>
>> Modified: lld/trunk/ELF/LinkerScript.cpp
>> URL: http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/LinkerScri
>> pt.cpp?rev=293963&r1=293962&r2=293963&view=diff
>> ============================================================
>> ==================
>> --- lld/trunk/ELF/LinkerScript.cpp (original)
>> +++ lld/trunk/ELF/LinkerScript.cpp Thu Feb  2 17:26:12 2017
>> @@ -696,9 +696,28 @@ static bool shouldSkip(const BaseCommand
>>    return Assign->Name != ".";
>>  }
>>
>> -// Orphan sections are sections present in the input files which are not
>> -// explicitly placed into the output file by the linker script. This just
>> -// places them in the order already decided in OutputSections.
>> +// Orphan sections are sections present in the input files which are
>> +// not explicitly placed into the output file by the linker script.
>> +//
>> +// When the control reaches this function, Opt.Commands contains
>> +// output section commands for non-orphan sections only. This function
>> +// adds new elements for orphan sections to Opt.Commands so that all
>> +// sections are explicitly handled by Opt.Commands.
>> +//
>> +// Writer<ELFT>::sortSections has already sorted output sections.
>> +// What we need to do is to scan OutputSections vector and
>> +// Opt.Commands in parallel to find orphan sections. If there is an
>> +// output section that doesn't have a corresponding entry in
>> +// Opt.Commands, we will insert a new entry to Opt.Commands.
>> +//
>> +// There is some ambiguity as to where exactly a new entry should be
>> +// inserted, because Opt.Commands contains not only output section
>> +// commands but other types of commands such as symbol assignment
>> +// expressions. There's no correct answer here due to the lack of the
>> +// formal specification of the linker script. We use heuristics to
>> +// determine whether a new output command should be added before or
>> +// after another commands. For the details, look at shouldSkip
>> +// function.
>>
>
> Can you mention compatibility with BFD/gold? IIRC orphan section handling
> was one of the issues with linking a working FreeBSD kernel. Also IIRC the
> GNU linkers actually have a well-defined default behavior (See
> --orphan-handling=MODE in https://sourceware.org/
> binutils/docs/ld/Options.html#Options and https://sourceware.org/
> binutils/docs/ld/Orphan-Sections.html#Orphan-Sections)
>
> -- Sean Silva
>
>
>>  template <class ELFT> void LinkerScript<ELFT>::placeOrphanSections() {
>>    // The OutputSections are already in the correct order.
>>    // This loops creates or moves commands as needed so that they are in
>> the
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170206/bd926b34/attachment.html>


More information about the llvm-commits mailing list