[PATCH] D22683: [ELF] Symbol assignment within input section list

[Rui Ueyama via llvm-commits]

On Thu, Jul 28, 2016 at 1:46 PM, Eugene Leviant <evgeny.leviant at gmail.com>
wrote:

>
>
> четверг, 28 июля 2016 г. пользователь Rui Ueyama написал:
>
> On Thu, Jul 28, 2016 at 1:22 PM, Eugene Leviant <evgeny.leviant at gmail.com>
>> wrote:
>>
>>> evgeny777 added inline comments.
>>>
>>> ================
>>> Comment at: ELF/LinkerScript.cpp:67
>>> @@ +66,3 @@
>>> +
>>> +  // This section should never be written.
>>> +  Hdr.sh_type = SHT_NOBITS;
>>> ----------------
>>> ruiu wrote:
>>> > It's a bit misleading. This section is written, but because it is
>>> empty, there's nothing to be written in reality.
>>> Not exactly. If you don't set SHT_NOBITS, lld will *attempt* to write
>>> the section and fail because file pointer is set to null.
>>
>>
>> Well, it's philosophical question whether .bss sections are "written" to
>> file or not. What I was trying to say is to ask you to make this comment
>> clear as to why we are doing this. We set NOBITS because it's a dummy
>> section just to anchor symbols that doesn't have contents.
>>
>>
>>> ================
>>> Comment at: ELF/LinkerScript.cpp:179-182
>>> @@ +178,6 @@
>>> +      for (const std::unique_ptr<BaseCommand> &Base2 : Cmd->Commands)
>>> +        if (auto *Assignment = dyn_cast<SymbolAssignment>(Base2.get()))
>>> +          PendingSymbols.push_back(Assignment);
>>> +        else
>>> +          AddMultiple(Cmd->Name,
>>> cast<InputSectionDescription>(Base2.get()));
>>> +
>>> ----------------
>>> ruiu wrote:
>>> > I do not understand why you needed a concept of "pending" here. You
>>> can add a SymbolInputSection as soon as you see a new SymbolAssignment,
>>> can't you?
>>> Imagine the symbol is declared before any input section rule, like in
>>> the sample below:
>>>
>>> ```
>>> .foo : { begin_foo = .; *(.foo) }
>>> ```
>>>
>>> Which output section will own it? You can't create output section given
>>> symbol assignment command, because you know only section name, not section
>>> attributes, which can be obtained only from InputSectionBase<ELFT>.
>>
>>
>> This is why I think we shouldn't use Factory to create output sections in
>> the linker script. Factory has a logic to create output sectinos in a smart
>> way, but in the linker script, we need to create output sections just as
>> instructed by scripts. As soon as we see SECTIONS command, we should be
>> able to create an output section. It's related to
>> https://reviews.llvm.org/D22749.
>>
>
> May be it's possible to just implement Factory::register(name,
> type, attrs), where attrs is a combination of input section attributes? I
> wonder what should be done if input sections are not compatible, i.e.
> PROGBITS/NOBITS? Raise error?
>

I do not see a strong reason to consolidate logic to Factory class. I
believe we can simply have a separate class in LinkerScirpt. As to
impossible attribute combinations, we probably should raise an error.


>>
>
>>> Repository:
>>>   rL LLVM
>>>
>>> https://reviews.llvm.org/D22683
>>>
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160728/19da39fd/attachment.html>