<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hello Peter,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thank you for your help. I finally had some time to build LLD from source and confirmed that the (NOLOAD) directive does work properly in LLD 12.0.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I wanted to find out where this was fixed so I tried some different versions of LLD. I pulled versions 10.1 and 11.0 from llvm-project/releases and found that the issue is solved in both: the .stack section is shown as NOBITS in the elf file.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Best regards,</div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>Daniel Way</div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 1, 2020 at 7:32 PM Peter Smith <<a href="mailto:Peter.Smith@arm.com" target="_blank">Peter.Smith@arm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Daniel,<br>
<br>
>From looking at the code I would expect LLD to give the .stack section type SHT_NOBITS if (NOLOAD) is used. If (NOLOAD) is not used then it is difficult to tell what the type of the section should be as it is likely to depend on the type of the previous Output Section. It is possible that ld.bfd is inheriting the type and LLD is not. I recommend being as explicit as possible in the linker script and using (NOLOAD) if you can.<br>
<br>
A change since LLD 10.0 <a href="https://reviews.llvm.org/D64930" rel="noreferrer" target="_blank">https://reviews.llvm.org/D64930</a> may have made LLD closer to ld.bfd in this area. If you are able to try out LLD 11.0 when it releases (or build it from source) that would be great.<br>
<br>
If all else fails it would be great if you could raise a PR with an example so we can look into it. The lld --reproduce=<filename> can capture the dependencies.<br>
<br>
Peter<br>
<br>
________________________________________<br>
From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Daniel Way via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
Sent: 01 September 2020 08:26<br>
To: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
Subject: [llvm-dev] [lld] [arm] Linker Cannot Set Custom Section Type to NOBITS<br>
<br>
I am linking a program to be loaded in an ARM Cortex-M0+ based microcontroller. In the linker script, I have a section allocated for the stack which roughly looks like the following.<br>
.stack : { . += __stack_size__; } > ram<br>
<br>
Using the linker in the gcc arm toolchain, arm-none-eabi-ld, this section is automatically set to type NOBITS, however, when linking with version 10.0.0 of ld.lld, the section type is PROGBITS.<br>
Here is the output when using readelf.<br>
<br>
ld.lld<br>
Section Headers:<br>
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al<br>
...<br>
[ 5] .stack PROGBITS 1ffff000 0014f0 000400 00 A 0 0 1<br>
<br>
arm-none-eabi-ld<br>
Section Headers:<br>
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al<br>
...<br>
[ 5] .stack NOBITS 1ffff000 01f000 000400 00 WA 0 0 1<br>
<br>
Reading online, I found that I should add the (NOLOAD) directive to my linker script, so I tried the following.<br>
.stack (NOLOAD) : { . += __stack_size__; } > ram<br>
<br>
But this change to the linker script does not seem to affect the output ELF file. Interestingly, if I add the (NOLOAD) directive to the script's .data section, the .data section will change to type NOBITS.<br>
I'd like to know if I'm making any errors, either in the section definition itself or when I call the linker.<br>
<br>
Thank you,<br>
Daniel Way<br>
</blockquote></div>