[llvm-dev] [LLD] Placing more sections in same segment as data?

[Peter Smith via llvm-dev]

On Mon, 14 Oct 2019 at 19:57, Troy Johnson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I've noticed that lld keeps the data section more isolated than the gold
> or bfd linkers.  For example, readelf -l applied to the "same" executable
> linked with those three linkers reveals the following under "Section to
> Segment mapping":
>
> lld:
> 05     .data .got.plt .bss
>
> gold:
> 03     .eh_frame .init_array .fini_array .preinit_array .dynamic .got
> .got.plt .data .bss
>
> bfd:
> 05     .eh_frame .preinit_array .init_array .fini_array .dynamic .got
> .got.plt .data .bss
>
> This separation seems to result in lld creating two LOAD RW segments
> whenever gold or bfd would create only one.  For example, also from readelf
> -l output:
>
>   LOAD           0x0000000000001a80 0x0000000000203a80 0x0000000000203a80
>                  0x00000000000002a8 0x00000000000002a8  RW     0x1000
>   LOAD           0x0000000000001d28 0x0000000000204d28 0x0000000000204d28
>                  0x0000000000000060 0x000000000000015c  RW     0x1000
>
> Could someone explain why the lld behavior is different?  Is there a way
> to make it match the gold/bfd behavior?  I've looked through the options
> list and read some of the lld code, but so far have not been able to find a
> solution.
>
>
I think this is likely to be https://reviews.llvm.org/D58892 "Split RW
PT_LOAD on the PT_GNU_RELRO boundary", which was made as part of a
suggestion in a comment for a related change https://reviews.llvm.org/D56828  .
The root cause of the justification is that it enables better use of .
bss.rel.ro sections. Unfortunately other than turning off RELRO with
-znorelo I'm not aware of an easier way to change this behaviour. It may be
possible to write a linker script with a PHDRS command but I've not tried
it. If I were to try I'd start by getting the linker script from ld.bfd
--verbose, and then add a PHDRS command to it.

If there is a good case for needing the ld.bfd behaviour I suggest raising
a PR, I'm thinking that this could be configurable via a command line
option.

Hope this helps

Peter



> Thanks,
>
> *Troy Johnson, Ph.D.*  |  Manager & Lead, Compiler Optimization
>
> Cray, a Hewlett Packard Enterprise company
>
> 2131 Lindau Lane, Suite 1000  |  Bloomington, MN 55425
>
> troyj at cray.com <prosien at cray.com>  *www.cray.com <http://www.cray.com>*
>
> [image: signature_957042053] <https://www.cray.com/>
>
> [image: signature_921593785] <https://twitter.com/cray_inc>  [image:
> signature_1210040077]
> <https://www.youtube.com/channel/UCS483ZExauoVgpG8dLn5p1w>  [image:
> signature_152254817] <https://www.linkedin.com/company/cray-inc-/>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191015/accbfe3f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 26684 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191015/accbfe3f/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 1916 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191015/accbfe3f/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 1803 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191015/accbfe3f/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 1724 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191015/accbfe3f/attachment-0007.png>