Re: [PATCH 1/2] or1k: Add hard float support

[Richard Henderson <richard.henderson@linaro.org>]

On 4/16/24 07:04, Adhemerval Zanella Netto wrote:
> If I understond correctly the OpenRISC hard-float ABIs uses the same
> parameter passing ABI from soft-fp, similar of what ARM does with
> -mfloat-abi=softfp.  So the the shared objects built with/without
> -mhard-float should be interoperable, assuming hardware has hard-fp
> support.
> 
> However it does solve the potential problem a binary built with softfp
> loading a hardfp built shared object, or even trying to link with a
> static object with different ABI (and assuming a hardware without
> hard-fp support)..  It means that loader and ldconfig won't recognize
> shared objects with different floating-point objects if they are installed
> on the same system.
> 
> I don't think we have a strong policy regarding this, and historical
> there were ABI variants that followed this (like powerpc soft and hard),
> but most ABIs that support soft/hard floating-point usually advertise it
> through ElfXX_Ehdr::e_flags.
> 
> For instance, with arm:
> 
> $ cat << EOF > lib.c
> float foo_float (float x, float y)
> {
>    return x + y;
> }
> 
> double foo_double (double x, double y)
> {
>    return x + y;
> }
> EOF
> $ arm-glibc-linux-gnueabi-gcc -shared -o lib.so lib.c
> $ readelf -h lib.so | grep Flags
>    Flags:                             0x5000200, Version5 EABI, soft-float ABI
> $ arm-glibc-linux-gnueabihf-gcc -shared -o lib.so lib.c
> $ readelf -h lib.so | grep Flags
>    Flags:                             0x5000400, Version5 EABI, hard-float ABI

The typical reason for wanting an e_flags bit is because those architectures want the 
parameter passing to change when floating-point registers are available.

But for OpenRISC there is no separate floating-point register set.  All floating-point 
operations use the same general-purpose registers as for all integer operations.  So there 
is no point in a new parameter passing ABI.


r~