From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sH34HTa43mE/fQAAWB0awg (envelope-from ) for ; Wed, 12 Jan 2022 06:15:02 -0500 Received: by simark.ca (Postfix, from userid 112) id 705FA1F34E; Wed, 12 Jan 2022 06:15:01 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 8710F1EA69 for ; Wed, 12 Jan 2022 06:15:00 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E9A34393A413 for ; Wed, 12 Jan 2022 11:14:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E9A34393A413 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1641986100; bh=YS8bd2hTOTLBD6pdKg0VxzEqjuqOWIx5FEVoeBMsWJM=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=sKXFLux3ozHdeGTeX+mxHprbpAV3y20/odAItXlwt/p5nJvg2MNLLIgbKu3SxnqVm 4U2xcZBjvZgIrgpc+lr83tAt3F1Mt/vp8UpOjWwIcJmYlIHKjqq5V2IVUcEIbWwsRw JijKLV4bKN7tEdeXe9wc/IExlM6NQdMDG/WAr0R8= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 88C183858416 for ; Wed, 12 Jan 2022 11:14:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 88C183858416 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-407-jmVykhcWN8-aKh8tOmbxmA-1; Wed, 12 Jan 2022 06:14:37 -0500 X-MC-Unique: jmVykhcWN8-aKh8tOmbxmA-1 Received: by mail-wm1-f69.google.com with SMTP id c5-20020a1c3505000000b00345c92c27c6so3501700wma.2 for ; Wed, 12 Jan 2022 03:14:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=YS8bd2hTOTLBD6pdKg0VxzEqjuqOWIx5FEVoeBMsWJM=; b=xUysP04BMgGs+cz0GBpPeniAurtZB0zkD2Lbm+tSwJGTGegEaVJK9/xB7gU2z+ZJ5o MVy3XvO2wWtixUXsXvgmoJFFfdxw3+JKiK7JbxNDnEHB/c9XBA/MvHoYil5JXw2AeFhg AWiIFmHOIXQmRbmTwymLm6WS1P8ET1t6ADOYlrkIMMYXhSvQU0UXH+QtN6zuikXFoGzB FlRRGwt3iL1k1mmkOLknNby4sYxQqpH0XuJxozLXlPLwQYkeL7+cV0x/wWyJJ051RXWT EJ5qdRXiA85DzmZafs/qflPbzgNXbFPzj4mO1tf7IPDuPxR/G+0XqHInIEgvHFwXQnyA iSFw== X-Gm-Message-State: AOAM5308hfTEQSw7t1wo2GxQ6XjCpgPdomUtdshiIZA4oCd8o6VakFG5 XDhJb+SOfdz0JoDXsCc2dzGArm45n0kcLWVSHGXQGXzDGO9Fea2cnSutY0EjThKJOf8jGOcdaK7 ExEJxvPdEshFmbfx/b92wxw== X-Received: by 2002:a7b:ca50:: with SMTP id m16mr6354909wml.145.1641986075932; Wed, 12 Jan 2022 03:14:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJwAgHiktFeUYRi9Uj14CzQZnx+qlFwI1Df27Yadybspsy9/Pt50nwLe0GZ8102LfrVnTr1gJQ== X-Received: by 2002:a7b:ca50:: with SMTP id m16mr6354894wml.145.1641986075689; Wed, 12 Jan 2022 03:14:35 -0800 (PST) Received: from localhost (host86-188-49-82.range86-188.btcentralplus.com. [86.188.49.82]) by smtp.gmail.com with ESMTPSA id x6sm857543wrt.58.2022.01.12.03.14.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Jan 2022 03:14:35 -0800 (PST) Date: Wed, 12 Jan 2022 11:14:34 +0000 To: Luis Machado Subject: Re: [PATCH] [AArch64] Properly extract the reference to a return value from x8 Message-ID: <20220112111434.GL622389@redhat.com> References: <20220104172254.3665546-1-luis.machado@linaro.org> <20220111212219.4018309-1-luis.machado@linaro.org> MIME-Version: 1.0 In-Reply-To: <20220111212219.4018309-1-luis.machado@linaro.org> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 11:04:02 up 10 days, 19:58, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: , From: Andrew Burgess via Gdb-patches Reply-To: Andrew Burgess Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" * Luis Machado via Gdb-patches [2022-01-11 18:22:19 -0300]: > When running gdb.cp/non-trivial-retval.exp, the following shows up for > AArch64-Linux: > > Breakpoint 3, f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35 > 35 A a; > (gdb) finish > Run till exit from #0 f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35 > main () at /src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:163 > 163 B b = f2 (i1, i2); > Value returned is $6 = {a = -11952} > (gdb) > > The return value should be {a = 123} instead. This happens because the AArch64 > backend doesn't extract the return value from the correct location. GDB should > fetch a pointer to the memory location from X8. > > With the patch, gdb.cp/non-trivial-retval.exp has full passes on > AArch64-Linux Ubuntu 20.04/18.04. > > The problem only shows up with the "finish" command. The "call" command > works correctly and displays the correct return value. > > This is also related to PR gdb/28681 > (https://sourceware.org/bugzilla/show_bug.cgi?id=28681). > --- > gdb/aarch64-tdep.c | 21 +++++++++++++++++++-- > 1 file changed, 19 insertions(+), 2 deletions(-) > > diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c > index 63d626f90ac..0efb3834584 100644 > --- a/gdb/aarch64-tdep.c > +++ b/gdb/aarch64-tdep.c > @@ -2362,7 +2362,8 @@ aarch64_return_in_memory (struct gdbarch *gdbarch, struct type *type) > return 0; > } > > - if (TYPE_LENGTH (type) > 16) > + if (TYPE_LENGTH (type) > 16 > + || !language_pass_by_reference (type).trivially_copyable) > { > /* PCS B.6 Aggregates larger than 16 bytes are passed by > invisible reference. */ > @@ -2474,8 +2475,24 @@ aarch64_return_value (struct gdbarch *gdbarch, struct value *func_value, > { > if (aarch64_return_in_memory (gdbarch, valtype)) > { > + /* From the AAPCS64's Result Return section: > + > + "Otherwise, the caller shall reserve a block of memory of > + sufficient size and alignment to hold the result. The address > + of the memory block shall be passed as an additional argument to > + the function in x8. */ > + > aarch64_debug_printf ("return value in memory"); > - return RETURN_VALUE_STRUCT_CONVENTION; > + > + if (readbuf) > + { > + CORE_ADDR addr; > + > + regcache->cooked_read (AARCH64_STRUCT_RETURN_REGNUM, &addr); > + read_memory (addr, readbuf, TYPE_LENGTH (valtype)); > + } > + > + return RETURN_VALUE_ABI_RETURNS_ADDRESS; So now, anything that should be returned in memory is of type RETURN_VALUE_ABI_RETURNS_ADDRESS. This is interesting because it should have implications outside of gdb.cp/non-trivial-retval.exp. In gdb.cp/non-trivial-retval.exp we pass a small struct, which, for most 64-bit targets, would normally be passed in registers, but which, for aarch64 is required to be passed in memory. After this change I would expect larger structs (> 16 bytes) to now also work correctly in aarch64. Did you see any additional tests starting to pass after this commit? For example, given this test program: struct large_t { int array[32]; }; struct large_t func () { int i; struct large_t obj; for (i = 0; i < 32; ++i) obj.array[i] = i; return obj; } int main () { struct large_t obj = func (); return obj.array[0]; } On x86-64 this is what I see: $ gdb -q large-struct Reading symbols from large-struct... (gdb) set print elements 10 (gdb) break func Breakpoint 1 at 0x401116: file large-struct.c, line 12. (gdb) r Starting program: /tmp/large-struct Breakpoint 1, func () at large-struct.c:12 12 for (i = 0; i < 32; ++i) (gdb) finish Run till exit from #0 func () at large-struct.c:12 main () at large-struct.c:22 22 return obj.array[0]; Value returned is $1 = { array = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...} } (gdb) I would expect on aarch64 that the finish didn't work correctly before this patch, but now does. Is this what you see? If you did see other tests starting to pass then could you mention them in the commit message please. If not, could you add a test like the above to the testsuite. Otherwise, the change looks good to me. Thanks, Andrew