Re: Objcopy seems to consider tbss part of PTLOAD

[Nick Clifton]

Hi Vijay,

> but Im unsure about PT_TLS segment  consisting only of .tbss section like in 
> above case.

Why ?  It seems reasonable to me.

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

Right.  I think that this means that the problem lies with lld.
(When I try the same sequence of commands using the ld.bfd
everything works...)


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

AH - I think that I understand your question now.  The reason
is that the ELF_SECTION_IN_SEGMENT_1 macro is meant to check
if a section-to-segment assignment is potentially valid, but
not to enforce a specific assignment policy.  Thus it is possible
for a section of type SHF_TLS to be placed into a PT_LOAD
segment - there are other ways for the loader to determine that
the segment contains some thread local data - it is just not
very intuitive.  At least that is how I see it.

I think that you have come across a case where the BFD library's
section placement heuristics do not work correctly.  Although the
circumstances are rather strange.  Please feel free to file a bug
report about the problem, including your reproducer, and we can
investigate further.

Cheers
  Nick