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

Tue Oct 15 10:22:46 PDT 2019

Thanks, Peter.  That patch pointed me to the exact line of code that I needed to know about!

I don't think it needs to be configurable via the command line unless others run into a problem with this change, too.  I happened to be working with some other software (that I can't change) that made some overly strict assumptions about how things were linked and it did not like having the segments split up.

-Troy
________________________________
From: Peter Smith <peter.smith at linaro.org>
Sent: Tuesday, October 15, 2019 5:20 AM
To: Troy Johnson <troyj at cray.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [LLD] Placing more sections in same segment as data?

On Mon, 14 Oct 2019 at 19:57, Troy Johnson via llvm-dev <llvm-dev at lists.llvm.org<mailto: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<http://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<mailto:prosien at cray.com>  www.cray.com<http://www.cray.com>

[signature_957042053]<https://www.cray.com/>

[signature_921593785]<https://twitter.com/cray_inc>  [signature_1210040077] <https://www.youtube.com/channel/UCS483ZExauoVgpG8dLn5p1w>   [signature_152254817] <https://www.linkedin.com/company/cray-inc-/>

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto: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/e2982288/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 26684 bytes
Desc: Outlook-signature_.png
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191015/e2982288/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 1916 bytes
Desc: Outlook-signature_.png
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191015/e2982288/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 1803 bytes
Desc: Outlook-signature_.png
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191015/e2982288/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 1724 bytes
Desc: Outlook-signature_.png
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191015/e2982288/attachment-0003.png>