On Thu, 29 Jun 2023 13:12:26 +0200 Thomas Huth <th...@redhat.com> wrote:
> On 29/06/2023 12.58, Claudio Imbrenda wrote: > > On Thu, 29 Jun 2023 12:48:21 +0200 > > Thomas Huth <th...@redhat.com> wrote: > > > >> start.S currently cannot be compiled with Clang 16 and binutils 2.40: > >> > >> ld: start.o(.text+0x8): misaligned symbol `__bss_start' (0xc1e5) for > >> relocation R_390_PC32DBL > >> > >> According to the built-in linker script of ld, the symbol __bss_start > >> can actually point *before* the .bss section and does not need to have > >> any alignment, so in certain situations (like when using the internal > >> assembler of Clang), the __bss_start symbol can indeed be unaligned > >> and thus it is not suitable for being used with the "larl" instruction > >> that needs an address that is at least aligned to halfwords. > >> The problem went unnoticed so far since binutils <= 2.39 did not > >> check the alignment, but starting with binutils 2.40, such unaligned > >> addresses are now refused. > >> > >> Fix it by loading the address indirectly instead. > > > > what are the advantages of this solution compared to your previous one > > (i.e. align .bss) ? > > __bss_start is supposed to point to an address that is before all bss-like > segments. There are also segments like .sbss and .bss.plt on other > architectures, see https://bugzilla.redhat.com/show_bug.cgi?id=2216662#c11 . > Seems like we don't have them on s390x yet, so currently my previous patch > is fine, too. But in case there will ever be an extension to the s390x ABI > that introduces such additional segments, we have to switch back to > __bss_start again. So it sounds slightly more future-proof to me to keep > __bss_start here, even if we need a slightly more complex startup code here > now. fair enough Reviewed-by: Claudio Imbrenda <imbre...@linux.ibm.com> > > Thomas > >