[RFC] Make __bss_start point at actual start of .bss

[Andreas Krebbel]

On 6/23/23 12:15, Alan Modra wrote:
> On Fri, Jun 23, 2023 at 08:37:33AM +0200, Andreas Krebbel via Binutils wrote:
>> While we could add platform-dependent alignment for the symbol here I'm wondering whether
>> we perhaps should rather move __bss_start into the .bss section definition in order to have it point
>> at the actual start of the section.
> 
> The question is, how is __bss_start used?  Is it the start of the .bss
> section or the start of the bss segment?  I think it is mainly used as
> the start of the segment, when loaders zero out all bss memory, so it
> should stay before other bss-style sections like .sbss.

The usage which triggered the problem came from qemu and the code there clears memory from
__bss_start through _end. This should work. It would fall short if somebody would actually just
clear __bss_start + sizeof(.bss).
Nick suggested to use the .bss section symbol instead of __bss_start. This looks like a good
workaround to me. We will miss clearing the padding bytes of the data section then, but this
shouldn't be a problem.
We nevertheless have to fix the issue with __bss_start for z.

> 
> The comment in elf.sc about OTHER_BSS_SYMBOLS dates to commit
> bff600cfa4e0, where despite the comment, __bss_start was left as the
> start of the segment.
> Aligning before __bss_start is likely the best thing to do.  If the
> first two output sections in the bss segment were .sbss and .bss then
> ALIGN (ALIGNOF(.sbss)!=0 ? ALIGNOF(.sbss) : ALIGNOF(.bss))
> ought to work.

For z it isn't really about aligning the symbol the same way as .bss. It rather is about applying an
alignment requirement mandated by the ABI. Would it perhaps make sense to introduce a variable
ABI_ALIGNMENT which could be used in the linker script template for aligning all free-floating symbols.

Bye,

Andreas