Re: [PATCH] gdb: mips: Fix the handling of complex type of function return value

[Youling Tang <tangyouling@loongson.cn>]

Hi, Maciej

On 03/17/2022 02:26 AM, Maciej W. Rozycki wrote:
> On Wed, 16 Mar 2022, Andrew Burgess wrote:
>
>>>>> $ objdump -d outputs/gdb.base/varargs/varargs
>>>>> 00000001200012e8 <find_max_float_real>:
>>>>> ...
>>>>>      1200013b8:   c7c10000        lwc1    $f1,0(s8)
>>>>>      1200013bc:   c7c00004        lwc1    $f0,4(s8)
>>>>>      1200013c0:   46000886        mov.s   $f2,$f1
>>>>>      1200013c4:   46000046        mov.s   $f1,$f0
>>>>>      1200013c8:   46001006        mov.s   $f0,$f2
>>>>>      1200013cc:   46000886        mov.s   $f2,$f1
>>>>>      1200013d0:   03c0e825        move    sp,s8
>>>>>      1200013d4:   dfbe0038        ld      s8,56(sp)
>>>>>      1200013d8:   67bd0080        daddiu  sp,sp,128
>>>>>      1200013dc:   03e00008        jr      ra
>>>>>      1200013e0:   00000000        nop
>>>>>
>>>>>   From the above disassembly, we can see that when the return value of the
>>>>> function is a complex type and len <= 2 * MIPS64_REGSIZE, the return value
>>>>> will be passed through $f0 and $f2, so fix the corresponding processing
>>>>> in mips_n32n64_return_value().
>>>>>
>>>>> $ make check RUNTESTFLAGS='GDB=../gdb gdb.base/varargs.exp --outdir=test'
>>>>>
>>>>> Before applying the patch:
>>>>>    FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, fc4)
>>>>>    FAIL: gdb.base/varargs.exp: print find_max_double_real(4, dc1, dc2, dc3, dc4)
>>>>>
>>>>>    # of expected passes		9
>>>>>    # of unexpected failures	2
>>>>>
>>>>> After applying the patch:
>>>>>    # of expected passes            11
>>>>>
>>>>> Signed-off-by: Youling Tang <tangyouling@loongson.cn>
>>>>> ---
>>>>>    gdb/mips-tdep.c | 3 ++-
>>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/gdb/mips-tdep.c b/gdb/mips-tdep.c
>>>>> index 7e37578..cddb8f8 100644
>>>>> --- a/gdb/mips-tdep.c
>>>>> +++ b/gdb/mips-tdep.c
>>>>> @@ -5224,9 +5224,10 @@ mips_n32n64_return_value (struct gdbarch *gdbarch, struct value *function,
>>>>>    
>>>>>      if (TYPE_LENGTH (type) > 2 * MIPS64_REGSIZE)
>>>>>        return RETURN_VALUE_STRUCT_CONVENTION;
>>>>> -  else if (type->code () == TYPE_CODE_FLT
>>>>> +  else if ((type->code () == TYPE_CODE_FLT
>>>>>    	   && TYPE_LENGTH (type) == 16
>>>>>    	   && tdep->mips_fpu_type != MIPS_FPU_NONE)
>>>> Hi,
>>>>
>>>> Just minor note, those 2 lines above should be indented 2 more space I
>>>> think (so the && operator continues to vertically align with "type->code
>>>> ()").
>>>>
>>>>> +	   || (type->code () == TYPE_CODE_COMPLEX))
>>>> I do not think the extra set of parens are requires (but they do no harm
>>>> either).
>>> Ok, I will modify this code style in the next version.
>> This change looks good to me with the style adjusments that Lancelot
>> pointed out.
>   This has to be double-checked, because as I recall we have an ABI bug in
> GCC in this area.  Which is also the reason why the relevant test cases
> have not been fixed in 15+ years now (I've been aware of this issue).
>
>   OTOH, if things have been like this for so long, then I suppose they need
> to stay as they are.  In any case I think this does have to be thoroughly
> understood and documented.
Thanks for your pointing out.If GCC's processing does not follow the ABI
call parameter specification, then this will be a GCC bug.GDB will remain
as is, without relevant modifications.

Thanks,
Youling.
>
>    Maciej