From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 53DCF385782D for ; Thu, 17 Mar 2022 07:01:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 53DCF385782D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from [10.130.0.193] (unknown [113.200.148.30]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9Dx3xPc3DJiYLgKAA--.8339S3; Thu, 17 Mar 2022 15:01:49 +0800 (CST) Subject: Re: [PATCH] gdb: mips: Fix the handling of complex type of function return value To: "Maciej W. Rozycki" References: <1647406106-25723-1-git-send-email-tangyouling@loongson.cn> <20220316084248.m5m2et3njtngeoge@Plymouth> <877d8uuop8.fsf@redhat.com> Cc: Andrew Burgess , Lancelot SIX , gdb-patches@sourceware.org From: Youling Tang Message-ID: Date: Thu, 17 Mar 2022 15:01:47 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: X-CM-TRANSID: AQAAf9Dx3xPc3DJiYLgKAA--.8339S3 X-Coremail-Antispam: 1UD129KBjvJXoWxWF1rtr13WFy8Gr1fuw43Awb_yoW5WF1Dpr WakrsruFZ5Jw1IyF9rKw4UXr4fCr47KrWUGrWF9rZ8ua15W3s3C3y7tr4YkrnrCws5try7 JwsxtFyjvF4xA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkIb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487McIj6xIIjxv2 0xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7 xvr2IY64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK 82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWw C20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48J MIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMI IF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU5fCztUUUUU== X-CM-SenderInfo: 5wdqw5prxox03j6o00pqjv00gofq/ X-Spam-Status: No, score=-13.5 required=5.0 tests=BAYES_00, GIT_PATCH_0, HTML_MESSAGE, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2022 07:02:02 -0000 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 : >>>>> ... >>>>> 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 >>>>> --- >>>>> 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