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

Andrew Burgess via Gdb-patches
2022-03-16T11:22:51Z

Youling Tang <tangyouling@loongson.cn> writes:

> Hi, Lancelo
>
> On 03/16/2022 04:42 PM, Lancelot SIX wrote:
>> On Wed, Mar 16, 2022 at 12:48:26PM +0800, Youling Tang 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.

Thanks,
Andrew