[PATCH] D24230: [ELF] Linkerscript: Fix handling of empty sections

[Eugene Leviant via llvm-commits]

2016-09-08 4:09 GMT+03:00 Rui Ueyama <ruiu at google.com>:

> On Wed, Sep 7, 2016 at 2:22 AM, Eugene Leviant <evgeny.leviant at gmail.com>
> wrote:
>
>> evgeny777 added a comment.
>>
>> > I'm wondering why we need to remove empty output sections from output.
>> I cannot think of a reason to not leave them as is except small
>> file/virtual address space wastes for the section table slot for the empty
>> section. Do we need to handle it as a special case?
>>
>>
>> Besides wasting some (small) space in ELF image I see two potential issues
>>
>> a) What type and attributes will you assign for those empty sections? If
>> you flag them with SHF_ALLOC you may end up having extra LOAD segments in
>> ELF image. If you don't, then you'll have to treat them specially in
>> assignAddresses.
>>
>
> If you do the latter, you'd probably need to add only a few lines to
> assignAddresses, which seems a fairly good deal.
>
> b) All "special" sections listed in linker script (like .got, .eh_frame
>> and so on) will have duplicates in ELF image, because they don't consist of
>> input sections. I don't know if this is a real problem, but looks confusing
>> at the very least (IMHO)
>>
>
> By duplicates, do you mean we'll end up having two or more special
> sections with the same name (e.g. having two .got sections)? If so, I think
> I don't understand how this would happen. What am I missing?
>

Imagine you have something like this in the linker script:

SECTIONS {
  ...
  .got : {}
  ...
}

This is sometimes used to specify section position in the list of output
sections. Linker script processor will see this line, create empty .got
section and add it to OutputSections.
After that real .got section will be added to the list in
finalizeSections() and you'll end up having 2 .got sections in result
image, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160908/f156c0ca/attachment.html>