Troy Johnson via llvm-dev
2019-Oct-14 18:57 UTC
[llvm-dev] [LLD] Placing more sections in same segment as data?
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.
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-/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191014/b633987e/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/20191014/b633987e/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/20191014/b633987e/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/20191014/b633987e/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/20191014/b633987e/attachment-0003.png>
Peter Smith via llvm-dev
2019-Oct-15 10:20 UTC
[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> 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>
Troy Johnson via llvm-dev
2019-Oct-15 17:22 UTC
[llvm-dev] [LLD] Placing more sections in same segment as data?
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>
Possibly Parallel Threads
- “Stripped-down” SSH (no encryption or authentication, just forwarding)
- Google Season of Docs: Requesting feedback on LLVM docs site updates
- Re: “Stripped-down” SSH (no encryption or authentication, just forwarding)
- Easy way to add common pass for optimization
- clarification on gosub, macros and AEL