Re: [PATCH] AArch64: Allow additional sizes in prologue

[Alan Hayward <Alan.Hayward@arm.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 5533 bytes --]



> On 6 Aug 2019, at 10:56, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> 
> On 06/08/2019 09:58, Alan Hayward wrote:
>>> On 5 Aug 2019, at 18:43, Tom Tromey <tom@tromey.com> wrote:
>>> 
>>>>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:
>>> 
>>> Alan> When saving registers to the stack at the start of a function, not all state
>>> Alan> needs to be saved. For example, only the first 64bits of float registers need
>>> Alan> saving.  However, a program may choose to store extra state if it wishes,
>>> Alan> there is nothing preventing it doing so.
>>> 
>>> Alan> The aarch64_analyze_prologue will error if it detects extra state being
>>> Alan> stored.  Relex this restriction.
>>> 
>>> I don't know anything about AArch64, so I can't really comment on the
>>> content of the patch, but I did happen to see a nit:
>>> 
>>> Alan>  	  stack.store (pv_add_constant (regs[rn],
>>> Alan>  					inst.operands[1].addr.offset.imm),
>>> Alan> -		       is64 ? 8 : 4, regs[rt]);
>>> Alan> +					size, regs[rt]);
>>> 
>>> ...this addition looked mis-indented to me.
>> Thanks.
>> I probably missed that because the correct formatting looks horrible:
>> 	  stack.store (pv_add_constant (regs[rn],
>> 					inst.operands[1].addr.offset.imm),
>> 		       size, regs[rt]);
>> Instead, I can update it to the following
>> 	  stack.store (
>> 	    pv_add_constant (regs[rn], inst.operands[1].addr.offset.imm),
>> 	    size, regs[rt]);
> 
> I think the coding convention in that case is to write:
> 
> 
> 	  stack.store
>            (pv_add_constant (regs[rn], inst.operands[1].addr.offset.imm),
> 	     size, regs[rt]);
> 
> R.

Ok, will use that way.

Alan.
From gdb-patches-return-157997-listarch-gdb-patches=sources.redhat.com@sourceware.org Tue Aug 06 13:50:35 2019
Return-Path: <gdb-patches-return-157997-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-patches@sources.redhat.com
Received: (qmail 27702 invoked by alias); 6 Aug 2019 13:50:34 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Delivered-To: mailing list gdb-patches@sourceware.org
Received: (qmail 27689 invoked by uid 89); 6 Aug 2019 13:50:34 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:629
X-HELO: gateway30.websitewelcome.com
Received: from gateway30.websitewelcome.com (HELO gateway30.websitewelcome.com) (192.185.197.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Aug 2019 13:50:32 +0000
Received: from cm11.websitewelcome.com (cm11.websitewelcome.com [100.42.49.5])	by gateway30.websitewelcome.com (Postfix) with ESMTP id 0C11036CE3	for <gdb-patches@sourceware.org>; Tue,  6 Aug 2019 08:50:31 -0500 (CDT)
Received: from box5379.bluehost.com ([162.241.216.53])	by cmsmtp with SMTP	id uzrDhNHs5dnCeuzrDhp9lt; Tue, 06 Aug 2019 08:50:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com;	 sÞfault; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:	References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:	Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:	Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:	List-Subscribe:List-Post:List-Owner:List-Archive;	bhÌ5bIVMIyPWW4OXyvFlyNEoQc3yCNHiWj+I9p1xC+fs=; b=dhFOQ7jaA92KoTi3ABnCgM/qSf	NQwKX7b5QqdetvdYB/eE5pgRkF64eIeQfnK7REaULAo/z1pd7e7te0muz+pOTyj4VZ5jBK3mI6hX7	CfqwWcJYEgzFE+ZH+QWVG/rBk;
Received: from 97-122-178-82.hlrn.qwest.net ([97.122.178.82]:51666 helo=murgatroyd)	by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)	(Exim 4.92)	(envelope-from <tom@tromey.com>)	id 1huzrC-001Rfp-PS; Tue, 06 Aug 2019 08:50:30 -0500
From: Tom Tromey <tom@tromey.com>
To: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
Cc: Christian Biesinger <cbiesinger@google.com>
Subject: Re: [PATCH] Replace int with enum block_enum where appropriate.
References: <20190805185833.236434-1-cbiesinger@google.com>
Date: Tue, 06 Aug 2019 13:50:00 -0000
In-Reply-To: <20190805185833.236434-1-cbiesinger@google.com> (Christian	Biesinger via gdb-patches's message of "Mon, 5 Aug 2019 13:58:33	-0500")
Message-ID: <874l2ubdy2.fsf@tromey.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SW-Source: 2019-08/txt/msg00134.txt.bz2
Content-length: 573

>>>>> "Christian" == Christian Biesinger via gdb-patches <gdb-patches@sourceware.org> writes:

Christian> For better readability and type safety.
Christian> gdb/ChangeLog:

Christian> 2019-08-05  Christian Biesinger  <cbiesinger@google.com>

Christian> 	* symtab.c (symbol_cache_lookup): Change int to enum block_enum.
Christian> 	(error_in_psymtab_expansion): Likewise.
Christian> 	(lookup_symbol_via_quick_fns): Likewise.
Christian> 	(basic_lookup_transparent_type_quick): Likewise.
Christian> 	(basic_lookup_transparent_type_1): Likewise.

Thank you.  This is ok.

Tom