[PATCH] D20378: [lld] Wrong section VMA/LMA in case of using linker scripts

[Rui Ueyama via llvm-commits]

I think that's the same behavior as the other linkers, no? At least
creating two or more output sections if section attributes are different is
a good thing to do.

On Thu, May 19, 2016 at 10:43 AM, Dima Stepanov <dstepanov.src at gmail.com>
wrote:

> Just want to add some more clarification here. It looks like for the
> current lld code it is an expected behaviour to create two sections. The
> main function to create the section key is ELF/Writer.cpp:createKey():
>  return SectionKey<ELFT::Is64Bits>{OutsecName, Type, Flags, Alignment};
> So there are 4 arguments to generate the key. And even more, there is a
> small comment about it:
>   // For SHF_MERGE we create different output sections for each alignment.
>   // This makes each output section simple and keeps a single level
> mapping from
>   // input to output.
> I can't say if it is good in general, but looks like an expected behaviour.
>
> Also two sections can be created even without a linker script. I tried to
> describe this case in https://llvm.org/bugs/show_bug.cgi?id=27805. In
> this case there are two .rodata sections with different alignment values.
> The good thing here is that without linker script another procedure is used
> to set the VMA/LMA fields (it just go through all the sections). This
> approach can't be used as is in case of the linker script.
>
>
> On Thu, May 19, 2016 at 9:50 AM, Rui Ueyama <ruiu at google.com> wrote:
>
>> ruiu accepted this revision.
>> ruiu added a reviewer: ruiu.
>> ruiu added a comment.
>> This revision is now accepted and ready to land.
>>
>> LGTM
>>
>> I'm singing off since this patch itself doesn't at least make things
>> worse, and and the new test make it explicit what we are doing.
>>
>>
>> Repository:
>>   rL LLVM
>>
>> http://reviews.llvm.org/D20378
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160519/0b3dda41/attachment.html>