From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) by sourceware.org (Postfix) with ESMTPS id 8E574393A418 for ; Tue, 11 Jan 2022 21:17:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E574393A418 Received: by mail-ua1-x930.google.com with SMTP id c36so977434uae.13 for ; Tue, 11 Jan 2022 13:17:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rLieFlUDuyirA2MumVcx7cczImYvUAvmbyFRfAm60Ic=; b=3YxL6zhbb3fZv210iCUW0mfAsVJ2dP5kEzrSvtyB2Z9sda/Ubv+VOQNAgRxHqudhAh Rfg/9tI5CeD3A6JYUqs1oEIpvYDL6JfiOK63z3O1oLNjLAsWTx/jgMizyRouNE1E0Qv6 endXmB8edf8ZNFSQI5tEn49dO5zSbh/pq0DbWzyxT25t8heTtJQdxM3euf75GJ2mtY5j oBCLiov6K3piz6f+WoDhjrNO5Q/VvAweI49cgOz++lANNr0kuCJ03ss68s1Fh6uQBeAU 0nnCbPp4BpAhYFjSB7/Mf2MGPOSMkN2Rz1GnDKMHf/rWCXipYsplKfONT7aTYmuuy8/q jtyQ== X-Gm-Message-State: AOAM530YHK8AkhkBfhO6UnKUOO/KjCOQAS2FefmoM1IRrBYsnkctjLsm mVQWOfF7JwBUodWbfjKojCEEjxCMQHBTPQ== X-Google-Smtp-Source: ABdhPJzRLSobc3IPrnNb+K/h5X07tnHmImG7jF+f1QiuPIElHPk4uu++VYNWEj2RcdKTAtvIfBnV2w== X-Received: by 2002:a67:b90a:: with SMTP id q10mr2946791vsn.35.1641935867284; Tue, 11 Jan 2022 13:17:47 -0800 (PST) Received: from ?IPv6:2804:7f0:4841:563b:7d4b:2a3c:90db:b35f? ([2804:7f0:4841:563b:7d4b:2a3c:90db:b35f]) by smtp.gmail.com with ESMTPSA id u124sm6195746vkg.3.2022.01.11.13.17.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Jan 2022 13:17:46 -0800 (PST) Subject: Re: [PATCH] [AArch64] Fix PR gdb/28681 To: Andrew Burgess Cc: gdb-patches@sourceware.org References: <20220104172254.3665546-1-luis.machado@linaro.org> <20220105125447.GF621762@redhat.com> From: Luis Machado Message-ID: <33ebf94c-16e8-50dd-fb86-e367de3833c2@linaro.org> Date: Tue, 11 Jan 2022 18:17:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20220105125447.GF621762@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: Tue, 11 Jan 2022 21:17:49 -0000 On 1/5/22 9:54 AM, Andrew Burgess wrote: > * Luis Machado [2022-01-04 14:22:54 -0300]: > >> This is the same as commit b1718fcdd1d2a5c514f8ee504ba07fb3f42b8608, but >> fixing things for AArch64. >> >> With the patch, gdb.cp/non-trivial-retval.exp has full passes on >> AArch64-Linux Ubuntu 20.04/18.04. >> --- >> gdb/aarch64-tdep.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c >> index 70fb66954a4..802762f303c 100644 >> --- a/gdb/aarch64-tdep.c >> +++ b/gdb/aarch64-tdep.c >> @@ -2323,6 +2323,15 @@ aarch64_extract_return_value (struct type *type, struct regcache *regs, >> valbuf += X_REGISTER_SIZE; >> } >> } >> + else if (!language_pass_by_reference (type).trivially_copyable) >> + { >> + /* If the object is a non-trivial C++ object, the result is passed as a >> + pointer stored in X0. */ >> + CORE_ADDR addr; >> + >> + regs->cooked_read (AARCH64_X0_REGNUM, &addr); >> + read_memory (addr, valbuf, TYPE_LENGTH (type)); >> + } >> else >> { >> /* For a structure or union the behaviour is as if the value had > > The aarch64_extract_return_value function is called exclusively from > aarch64_return_value. > > After calling this function the aarch64_return_value function returns > RETURN_VALUE_REGISTER_CONVENTION, which I don't think is correct in > the above case. > > I think we should be returning one of either > RETURN_VALUE_STRUCT_CONVENTION, RETURN_VALUE_ABI_RETURNS_ADDRESS or > RETURN_VALUE_ABI_PRESERVES_ADDRESS. Yes, it seems that way. The original return convention does not cover this particular case. The current code may actually be incorrect, and RETURN_VALUE_ABI_RETURNS_ADDRESS seems to be a more correct option. > > I wonder if aarch64_return_in_memory should be doing more of the work > in this case? But that's just a thought, I'm sure whatever you come > up with will be fine, so long as the return type is correct. Expanding aarch64_return_in_memory to check for non-trivially-copyable objects and filling in the readbuf with the right value should do it as well. I have an updated patch for this. Thanks, Luis