thr3ads.net - llvm dev - [llvm-dev] [LLD] Placing more sections in same segment as data? [Oct 2019]

If this information is useful, please help other people find it:
Share via:

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

head link

[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

head link

[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>

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

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

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

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