Hi Vijay,
In the future, it helps if report bugs, or potential bugs,
via the binutils bugzilla system. This allows us to track
bugs individually and also add comments in the code that
refer back to the bug report. https://sourceware.org/bugzilla/
Thanks, will keep this in mind.
clang reprod.c -ffreestanding -c -o reprod.img
Which architecture is this for ? Which versions of clang and
the binutils are you using ?
I'm using clang-17 and binutils 2.40 I have gotten this issue with x86_64 but this issue seems target agnostic.
ld.lld --defsym VMA_START=0xffffffff80100000 --defsym LMA_START=0x4800000 -T l.ld reprod.img -o reprod.img
objcopy --change-section-lma .*-0xffffffff80000000 reprod.img
objcopy --adjust-start -0xffffffff80000000 reprod.img
lld dosen't seem to consider tbss section to have proper lma
of lld
TLS 0x0000000000002058 0xffffffff80100060 (vma) 0xffffffff80100060 (lma)
0x0000000000000000 0x0000000000000004 R 0x4
03 .tbss
Ld Linker
TLS 0x0000000000100098 0xffffffff801000a0 (vma) 0xffffffffc81000a0 (lma)
0x0000000000000000 0x0000000000000004 R 0x4
I am sorry, but I did not understand what is wrong with the LMA.
Please could you explain some more.
Also, you say that objcopy does not consider the .tbss section
to be part of a PT_LOAD segment. This is correct. It is part
of a PT_TLS segment. PT_TLS segments are considered to be
inherently loadable, so it is OK to use PT_TLS for thread local
data rather than PT_LOAD.
Cheers
Nick
I am sorry for not being clear.
to clarify it looks like when PT_TLS segment is considered part of PT_LOAD which makes sense considering .tdata is part of LOAD.
but Im unsure about PT_TLS segment consisting only of .tbss section like in above case.
when objcopy does consider such a segment to be part of LOAD, when assigning offsets things seem to be going wrong
First issue we encounter.
to clarify it looks like when PT_TLS segment is considered part of PT_LOAD which makes sense considering .tdata is part of LOAD.
but Im unsure about PT_TLS segment consisting only of .tbss section like in above case.
when objcopy does consider such a segment to be part of LOAD, when assigning offsets things seem to be going wrong
First issue we encounter.
objcopy: stq0GBq2: section `.data' can't be allocated in segment 0
LOAD: .tbss .data .bss .sdata
objcopy: stq0GBq2: section `.bss' can't be allocated in segment 0
LOAD: .tbss .data .bss .sdata
second issue the image sizes are overblown
second issue the image sizes are overblown
du -sh a.out
34G a.out
all of this because lld seems to not emit LMA with a proper offset ie its LMA is just VMA not LMA+Offset.
segments are sorted and based on LMA ,based upon this the respective file-offsets are assigned and this is when things seem to be going wrong.
Is it expected that objcopy considers PT_TLS segment consisting only of tbss to be part of LOAD, since tbss is a special section I assumed it should have been dealt with differently ie not part of LOAD. if so could you explain reasoning behind this.
Thank you,
all of this because lld seems to not emit LMA with a proper offset ie its LMA is just VMA not LMA+Offset.
segments are sorted and based on LMA ,based upon this the respective file-offsets are assigned and this is when things seem to be going wrong.
Is it expected that objcopy considers PT_TLS segment consisting only of tbss to be part of LOAD, since tbss is a special section I assumed it should have been dealt with differently ie not part of LOAD. if so could you explain reasoning behind this.
Thank you,
~vijay
