From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75144 invoked by alias); 10 Jan 2017 11:28:01 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 75130 invoked by uid 89); 10 Jan 2017 11:28:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_50,KAM_LOTSOFHASH,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=descr, *descr, PACKET_P, regcache_descr X-HELO: EUR03-AM5-obe.outbound.protection.outlook.com Received: from mail-eopbgr30084.outbound.protection.outlook.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (40.107.3.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Jan 2017 11:27:50 +0000 Received: from VI1PR0801MB1822.eurprd08.prod.outlook.com (10.168.68.7) by VI1PR0801MB1823.eurprd08.prod.outlook.com (10.168.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Tue, 10 Jan 2017 11:27:47 +0000 Received: from VI1PR0801MB1822.eurprd08.prod.outlook.com ([10.168.68.7]) by VI1PR0801MB1822.eurprd08.prod.outlook.com ([10.168.68.7]) with mapi id 15.01.0803.021; Tue, 10 Jan 2017 11:27:47 +0000 From: Alan Hayward To: Luis Machado CC: "gdb-patches@sourceware.org" , nd Subject: Re: [PATCH 1/3] Use register_size () instead of MAX_REGISTER_SIZE Date: Tue, 10 Jan 2017 11:28:00 -0000 Message-ID: <04ADBC86-B250-482B-8634-A712604A7E93@arm.com> References: <902F747B-B822-4629-8DB8-D6775357E6A5@arm.com> <20085eca-52a3-ea33-9c9d-27f9064c986b@codesourcery.com> In-Reply-To: <20085eca-52a3-ea33-9c9d-27f9064c986b@codesourcery.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-office365-filtering-correlation-id: 0868fd40-3e22-4f8f-bc13-08d4394bb3f6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR0801MB1823; x-microsoft-exchange-diagnostics: 1;VI1PR0801MB1823;7:iJ1VBoFfdLv3cRNhvYxwN5ue57KwgXkDm/5YTmHaB26o1gR60mGBFsNMDL9lNd4ATP9oxoAVn/kELd+pT+p9l/tuPVgNfZ1EFuzOvqKNjZjaYPG5t82y8sNzHfQNkog7IEWU4hUKxBRwyzdETAmDlq/6357JKvtJILuLcnw8ZcpRUx8pDkuIQX+wbClpUVcJXtM4f+zLdRVuY2Q17eXlGYpFCgHU7bD8icIQ6T191q+7xLnv7hs8q3HtAbvXKQtuol1UmU9IbAYOjeWmDy235ZBytJAfjQ9Xl9WVtde2MI9jE0LyA7BSI5SnaEELmChIzM4dIZNsRmiaxxyLIgStSMGTyw8DMHxPVR3vPXWFWnkuIrn1YOKiS+191E1fLJKYHaYuu9B5PjCBd9xwGnzSDsQYkwN2Z/mWHWAMsXUse35Leb29NyJFjD1uSfkhbF1LT173R5zKuuIih2kNN3mpLQ== nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148);SRVR:VI1PR0801MB1823;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1823; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(39450400003)(39850400002)(39410400002)(39860400002)(39840400002)(377424004)(189002)(24454002)(51914003)(377454003)(199003)(77096006)(189998001)(38730400001)(7736002)(229853002)(33656002)(105586002)(6486002)(6506006)(106356001)(575784001)(102836003)(122556002)(86362001)(66066001)(2906002)(2950100002)(4326007)(36756003)(6916009)(6116002)(3846002)(76176999)(50986999)(106116001)(54356999)(2900100001)(5660300001)(110136003)(6436002)(92566002)(97736004)(305945005)(6512007)(99286003)(68736007)(25786008)(8676002)(8936002)(83716003)(3280700002)(3660700001)(54906002)(82746002)(81166006)(81156014)(101416001)(104396002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0801MB1823;H:VI1PR0801MB1822.eurprd08.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 11:27:46.9253 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1823 X-SW-Source: 2017-01/txt/msg00145.txt.bz2 > On 9 Jan 2017, at 20:07, Luis Machado wrote: >=20 > On 01/09/2017 04:55 AM, Alan Hayward wrote: >> Aarch64 SVE requires a max register size of 256. The current max size in= gdb >> is 64. This is part of a series demonstrating the replacement of >> MAX_REGISTER_SIZE. >>=20 >> In cases where a buffer is created to hold a single register, then >> MAX_REGISTER_SIZE can be replaced with a call to register_size (). >>=20 >> This patch is restricted to amd64-tdep.c, remote.c and regcache.c. >> Follow on patch sets will expand to other files. >>=20 >> Tested on x86. >> Ok to commit? >>=20 >> Thanks, >> Alan. >>=20 >> 2017-01-09 Alan Hayward >>=20 >> * amd64-tdep.c (amd64_pseudo_register_read_value): remove >> MAX_REGISTER_SIZE. >> (amd64_pseudo_register_read_value): Likewise. >> * remote.c (fetch_register_using_p): Remove MAX_REGISTER_SIZE. >> (store_register_using_P): Likewise. >> * regcache.c (regcache_xfer_part): Likewise. >>=20 >>=20 >> diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c >> index a6367424e75b234c89e05b2dba7490ac3e212c3c..fc1f134a18098862fab92ad4= 5e55b05372027beb 100644 >> --- a/gdb/amd64-tdep.c >> +++ b/gdb/amd64-tdep.c >> @@ -353,7 +353,7 @@ amd64_pseudo_register_read_value (struct gdbarch *gd= barch, >> struct regcache *regcache, >> int regnum) >> { >> - gdb_byte raw_buf[MAX_REGISTER_SIZE]; >> + gdb_byte *raw_buf =3D (gdb_byte *) alloca (register_size (gdbarch, re= gnum)); >> struct gdbarch_tdep *tdep =3D gdbarch_tdep (gdbarch); >> enum register_status status; >> struct value *result_value; >> @@ -414,7 +414,7 @@ amd64_pseudo_register_write (struct gdbarch *gdbarch, >> struct regcache *regcache, >> int regnum, const gdb_byte *buf) >> { >> - gdb_byte raw_buf[MAX_REGISTER_SIZE]; >> + gdb_byte *raw_buf =3D (gdb_byte *) alloca (register_size (gdbarch, re= gnum)); >> struct gdbarch_tdep *tdep =3D gdbarch_tdep (gdbarch); >>=20 >> if (i386_byte_regnum_p (gdbarch, regnum)) >> diff --git a/gdb/regcache.c b/gdb/regcache.c >> index b2b9524d742a477f89195cf657085833054cbb38..9d28aa2c2114e0f1c52758bb= 2fbe9669a329c13e 100644 >> --- a/gdb/regcache.c >> +++ b/gdb/regcache.c >> @@ -988,7 +988,8 @@ regcache_xfer_part (struct regcache *regcache, int r= egnum, >> const gdb_byte *buf)) >> { >> struct regcache_descr *descr =3D regcache->descr; >> - gdb_byte reg[MAX_REGISTER_SIZE]; >> + struct gdbarch *gdbarch =3D get_regcache_arch (regcache); >> + gdb_byte *reg =3D (gdb_byte *) alloca (register_size (gdbarch, regnum= )); >>=20 >> gdb_assert (offset >=3D 0 && offset <=3D descr->sizeof_register[regnum= ]); >> gdb_assert (len >=3D 0 && offset + len <=3D descr->sizeof_register[reg= num]); >> diff --git a/gdb/remote.c b/gdb/remote.c >> index 837b9ee5124e8ac3f4e3a55279adae49c790be19..6da6eb366ae442354fd6a377= 41335af9a4a5a056 100644 >> --- a/gdb/remote.c >> +++ b/gdb/remote.c >> @@ -7462,9 +7462,10 @@ remote_wait (struct target_ops *ops, >> static int >> fetch_register_using_p (struct regcache *regcache, struct packet_reg *re= g) >> { >> + struct gdbarch *gdbarch =3D get_regcache_arch (regcache); >> struct remote_state *rs =3D get_remote_state (); >> char *buf, *p; >> - char regp[MAX_REGISTER_SIZE]; >> + gdb_byte *regp =3D (gdb_byte *) alloca (register_size (gdbarch, reg->= regnum)); >> int i; >>=20 >> if (packet_support (PACKET_p) =3D=3D PACKET_DISABLE) >> @@ -7769,7 +7770,7 @@ store_register_using_P (const struct regcache *reg= cache, >> struct remote_state *rs =3D get_remote_state (); >> /* Try storing a single register. */ >> char *buf =3D rs->buf; >> - gdb_byte regp[MAX_REGISTER_SIZE]; >> + gdb_byte *regp =3D (gdb_byte *) alloca (register_size (gdbarch, reg->= regnum)); >> char *p; >>=20 >> if (packet_support (PACKET_P) =3D=3D PACKET_DISABLE) >>=20 >>=20 >>=20 >>=20 >=20 > Patch looks OK to me. Are you planning on getting rid of all/most of the = MAX_REGISTER_SIZE in gdb? Yes, I plan to remove the define completely, because Aarch64 SVE support wo= uld have required MAX_REGISTER_SIZE to be changed from 64 to 256. Thanks for the review. Alan.