From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130426 invoked by alias); 4 Apr 2017 17:19:03 -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 130413 invoked by uid 89); 4 Apr 2017 17:19:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-23.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=ham version=3.3.2 spammy=research X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Apr 2017 17:18:59 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 8878310A7DB; Tue, 4 Apr 2017 13:18:58 -0400 (EDT) From: John Baldwin To: gdb-patches@sourceware.org Cc: Alan Hayward , nd Subject: Re: [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE Date: Tue, 04 Apr 2017 17:19:00 -0000 Message-ID: <4029978.dIfO0XF6y1@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <3C00280E-37C9-4C0A-9DA6-F3B9DB1A6E8F@arm.com> References: <3C00280E-37C9-4C0A-9DA6-F3B9DB1A6E8F@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00027.txt.bz2 On Tuesday, April 04, 2017 10:12:39 AM Alan Hayward wrote: > Max size set to 64bits, which I determined using the files regformats/mips*.dat > > Tested on a --enable-targets=all build using make check with board files > unix and native-gdbserver. > > I do not have a MIPS machine to test on. > > Ok to commit? I don't know how much we (GDB) care, but keep in mind that this does mean that these constants have to be updated as architectures change. In my case I'm working on a research CPU that extends MIPS with some 128 and 256-bit registers. This means that in my GDB patches for this processor I will need to bump this constant explicitly. That's probably not the end of the world, but this approach of per-arch constants vs a global constant does make that sort of thing slightly more complex to handle. > Alan. > > 2017-04-04 Alan Hayward > > * mips-fbsd-tdep.c (mips_fbsd_supply_reg): Use MIPS_MAX_REGISTER_SIZE. > (mips_fbsd_collect_reg): Likewise. > * mips-linux-tdep.c (supply_32bit_reg): Likewise. > (mips_supply_gregset): Likewise. > (mips_supply_fpregset): Likewise. > (mips64_supply_gregset): Likewise. > (mips64_fill_gregset): Likewise. > (mips64_fill_fpregset): Likewise. > * mips-tdep.c (mips_eabi_push_dummy_call): Likewise. > (mips_o32_return_value): Likewise. > (print_gp_register_row): Likewise. > * mips-tdep.h (MIPS_MAX_REGISTER_SIZE): Add > > > > diff --git a/gdb/mips-fbsd-tdep.c b/gdb/mips-fbsd-tdep.c > index 00fae0ec60ddc9e645d3236efe29f2f9e9ceab5c..cb696f7318a9da176fee2693e484ecf48346712c 100644 > --- a/gdb/mips-fbsd-tdep.c > +++ b/gdb/mips-fbsd-tdep.c > @@ -63,7 +63,7 @@ mips_fbsd_supply_reg (struct regcache *regcache, int regnum, const void *addr, > else > { > enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > - gdb_byte buf[MAX_REGISTER_SIZE]; > + gdb_byte buf[MIPS_MAX_REGISTER_SIZE]; > LONGEST val; > > val = extract_signed_integer ((const gdb_byte *) addr, len, byte_order); > @@ -90,7 +90,7 @@ mips_fbsd_collect_reg (const struct regcache *regcache, int regnum, void *addr, > else > { > enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > - gdb_byte buf[MAX_REGISTER_SIZE]; > + gdb_byte buf[MIPS_MAX_REGISTER_SIZE]; > LONGEST val; > > regcache_raw_collect (regcache, regnum, buf); This part is ok with me, but I can't approve changes so you will need additional review from an approver. -- John Baldwin