From patchwork Wed Apr 12 08:27:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alan Hayward X-Patchwork-Id: 19988 Received: (qmail 73034 invoked by alias); 12 Apr 2017 08:27:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 73002 invoked by uid 89); 12 Apr 2017 08:27:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, MIME_BASE64_BLANKS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy=regi X-HELO: EUR03-VE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr50084.outbound.protection.outlook.com (HELO EUR03-VE1-obe.outbound.protection.outlook.com) (40.107.5.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Apr 2017 08:27:54 +0000 Received: from AM3PR08MB0101.eurprd08.prod.outlook.com (10.160.211.19) by AM3PR08MB0102.eurprd08.prod.outlook.com (10.160.211.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Wed, 12 Apr 2017 08:27:52 +0000 Received: from AM3PR08MB0101.eurprd08.prod.outlook.com ([fe80::c065:778f:9924:8660]) by AM3PR08MB0101.eurprd08.prod.outlook.com ([fe80::c065:778f:9924:8660%14]) with mapi id 15.01.1019.026; Wed, 12 Apr 2017 08:27:52 +0000 From: Alan Hayward To: Yao Qi CC: "gdb-patches@sourceware.org" , nd Subject: Re: [PATCH 8/11] Add FRV_MAX_REGISTER_SIZE Date: Wed, 12 Apr 2017 08:27:52 +0000 Message-ID: References: <3B3BD949-1C9D-44FF-AB6A-03091ECA49D0@arm.com> <867f2rw9br.fsf@gmail.com> In-Reply-To: <867f2rw9br.fsf@gmail.com> authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=arm.com; x-ms-exchange-messagesentrepresentingtype: 1 x-microsoft-exchange-diagnostics: 1; AM3PR08MB0102; 7:Iij6SVm/MggV3R6liUXlz/K7TtsHrdS0o/cH5aiA+sJpq9/dit9WAt6lIOCazujEVZKYzeYSVD+TDjqr2uvcELC473NosZrRhEvzeikHIrhNW2VragSS9OUtC7YKs96mCarWndQCUiyM65kM1VXeL1kaUvOy8wETrBPHOVtFwp0dvByEU8DBHNKBQZHRNyx7Vx1E/1DXAqeLdxE1KtrAQkA3YoGUH0W4lVDCngAe3zbuYqipSOrNdwd9N4GwLq+aE7oJzzMLlN9MpEv4vmT6GqLhar9w51EXxWDXk2BhsXo8bONUgyQe2uXMOBlOtL8VGK7G+HdloVGVJkB5jKBzdw== x-ms-office365-filtering-correlation-id: f3d3447a-a1db-4878-729d-08d4817dd007 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM3PR08MB0102; nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:AM3PR08MB0102; BCL:0; PCL:0; RULEID:; SRVR:AM3PR08MB0102; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39840400002)(39860400002)(39450400003)(39410400002)(39400400002)(24454002)(377424004)(6486002)(5660300001)(8936002)(5250100002)(575784001)(4326008)(6506006)(8676002)(66066001)(3660700001)(229853002)(53936002)(81166006)(33656002)(39060400002)(6246003)(53546009)(86362001)(82746002)(83716003)(25786009)(76176999)(54356999)(50986999)(99286003)(7736002)(54906002)(6436002)(305945005)(38730400002)(6512007)(3280700002)(6916009)(2950100002)(1411001)(110136004)(2906002)(189998001)(2900100001)(36756003)(3846002)(102836003)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR08MB0102; H:AM3PR08MB0101.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2017 08:27:52.4344 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR08MB0102 > On 11 Apr 2017, at 11:02, Yao Qi wrote: > > Alan Hayward writes: > >> - char zerobuf[MAX_REGISTER_SIZE]; >> + char zerobuf[FRV_MAX_REGISTER_SIZE]; >> >> - memset (zerobuf, 0, MAX_REGISTER_SIZE); >> + memset (zerobuf, 0, FRV_MAX_REGISTER_SIZE); >> >> /* gr0 always contains 0. Also, the kernel passes the TBR value in >> this slot. */ > > The code here fills some gr registers with zeros, > > /* gr0 always contains 0. Also, the kernel passes the TBR value in > this slot. */ > regcache_raw_supply (regcache, first_gpr_regnum, zerobuf); > > /* Fill gr32, ..., gr63 with zeros. */ > for (regi = first_gpr_regnum + 32; regi <= last_gpr_regnum; regi++) > regcache_raw_supply (regcache, regi, zerobuf); > > the size of these gr registers are know, 8 bytes. It won't be changed. > We can do, > > gdb_byte zerobuf[8] = { 0 }; > > the code is still easy to read. If you really dislike magic number (IMO, 8 > is not a magic number in this context), you can define FRR_GR_REGISTER_SIZE. > > Alternatively, you can add a new regache api, regcache_raw_supply_zero. > Many places can use this api, and some uses of MAX_REGISTER_SIZE can be > removed too, for example, > > regcache_raw_supply (regcache, MIPS_ZERO_REGNUM, zerobuf); > > -- > Yao (齐尧) Went with the simpler solution. I don't have a FRV machine to test on. Tested on a --enable-targets=all build using make check with board files unix and native-gdbserver. Ok to commit? Alan. 2017-04-12 Alan Hayward * gdb/frv-linux-tdep.c (frv_linux_supply_gregset): Remove MAX_REGISTER_SIZE. diff --git a/gdb/frv-linux-tdep.c b/gdb/frv-linux-tdep.c index eb87f93058b0287e8f05c585d1b6aa1ff2bffb78..3f91bf0ee81a5d5ca915c88337c6a4b4ed53d344 100644 --- a/gdb/frv-linux-tdep.c +++ b/gdb/frv-linux-tdep.c @@ -413,9 +413,7 @@ frv_linux_supply_gregset (const struct regset *regset, int regnum, const void *gregs, size_t len) { int regi; - char zerobuf[MAX_REGISTER_SIZE]; - - memset (zerobuf, 0, MAX_REGISTER_SIZE); + gdb_byte zerobuf[8] = { 0 }; /* gr0 always contains 0. Also, the kernel passes the TBR value in this slot. */