qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 7/7] pc-bios/s390-ccw: Don't use __bss_start with the "lar


From: Thomas Huth
Subject: Re: [PATCH v3 7/7] pc-bios/s390-ccw: Don't use __bss_start with the "larl" instruction
Date: Thu, 29 Jun 2023 13:12:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0

On 29/06/2023 12.58, Claudio Imbrenda wrote:
On Thu, 29 Jun 2023 12:48:21 +0200
Thomas Huth <thuth@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.

 Thomas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]