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

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 16/04/24 11:53, Richard Henderson wrote:
> 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.

Right, it was not clear from patch without dig into the ABI documen
itself.  So the only thing I am not sure is the mcontext_t change.  
Other ABIs added a symbol version to proper handle it, so maybe 
OpenRISC would need something similar.