From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31808 invoked by alias); 2 Aug 2008 01:36:31 -0000 Received: (qmail 31800 invoked by uid 22791); 2 Aug 2008 01:36:30 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 02 Aug 2008 01:36:12 +0000 Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id m721a7gt005595 for ; Sat, 2 Aug 2008 02:36:07 +0100 Received: from rv-out-0506.google.com (rvbk40.prod.google.com [10.140.87.40]) by spaceape12.eur.corp.google.com with ESMTP id m721a5qa002192 for ; Fri, 1 Aug 2008 18:36:06 -0700 Received: by rv-out-0506.google.com with SMTP id k40so1277358rvb.57 for ; Fri, 01 Aug 2008 18:36:05 -0700 (PDT) Received: by 10.141.105.18 with SMTP id h18mr6281816rvm.207.1217640965599; Fri, 01 Aug 2008 18:36:05 -0700 (PDT) Received: by 10.140.135.3 with HTTP; Fri, 1 Aug 2008 18:36:05 -0700 (PDT) Message-ID: <498552560808011836i7f96ce5ds6c6e96bcdc895a37@mail.gmail.com> Date: Sat, 02 Aug 2008 01:36:00 -0000 From: "=?BIG5?B?RG91ZyBLd2FuICjD9q62vHcp?=" To: "=?BIG5?B?RG91ZyBLd2FuICjD9q62vHcp?=" , gdb-patches@sourceware.org Subject: Re: Does gdb ARM simulator support armv7? In-Reply-To: <20080801125524.GA13939@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=BIG5 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <498552560808010233k28f52beas8931aa251fd2f2dc@mail.gmail.com> <20080801125524.GA13939@caradoc.them.org> 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 X-SW-Source: 2008-08/txt/msg00021.txt.bz2 VGhhbmtzLiBxZW11IGRpZCB0aGUgdHJpY2sgZm9yIG1lLgoKLURvdWcKCjIw MDgvOC8xIERhbmllbCBKYWNvYm93aXR6IDxkcm93QGZhbHNlLm9yZz46Cj4g T24gRnJpLCBBdWcgMDEsIDIwMDggYXQgMDI6MzM6NTdBTSAtMDcwMCwgRG91 ZyBLd2FuICjD9q62vHcpIHdyb3RlOgo+PiBIaSwKPj4KPj4gICAgIEkgYW0g bm90IHN1cmUgdGhpcyBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gYXNrIHRoaXMg cXVlc3Rpb24gYnV0IEkKPj4gaG9wZSBwZW9wbGUgd29ya2luZyBvbiB0aGUg QVJNIHNpbSBjYW4gZ2l2ZSBtZSB0aGUgYW5zd2VyLiAgIEkgYW0KPj4gd29y a2luZyBvbiBhIGdjYyBwYXRjaCBhbmQgSSB3b3VsZCBsaWtlIHRvIHRlc3Qg bXkgcGF0Y2ggZm9yIGFybXY1LAo+PiBhcm12NiBhbmQgYXJtdjcuICBJIGdv dCBubyBwcm9ibGVtIHdpdGggYXJtdjUgYW5kIGEgZmV3IGlzc3VlcyB3aXRo Cj4+IGFybXY2IGJ1dCBJIHdvcmtlZCBhcm91bmQgdGhvc2UuICBXaXRoIGFy bXY3LCB0aGluZ3MgbG9va2VkIGJhZCB3aGVuIEkKPj4gdHJpZWQgdG8gcnVu IGdjYydzIHRlc3RzdWl0ZSB1c2luZyB0aGUgc2ltdWxhdG9yLiAgSSBsb29r ZWQgYXQgdGhlCj4+IHNpbXVsYXRvciBzb3VyY2UgY29kZSBhbmQgdGhlIENo YW5nZUxvZyBidXQgdGhlcmUgZGlkIG5vdCBzZWVtIHRvIGhhdmUKPj4gYW55 IG1lbnRpb25pbmcgb2YgVEhVTUIyIG9yIHY3LiAgRG9lcyB0aGUgZ251IEFS TSBzaW11bGF0b3Igc3VwcG9ydAo+PiBUSFVNQjI/Cj4KPiBObywgaXQgZG9l c24ndC4gIFlvdSBtYXkgaGF2ZSBiZXR0ZXIgbHVjayB3aXRoIHFlbXU7IHRo YXQncyB3aGF0IHdlCj4gdXNlIGZvciB0ZXN0aW5nLCBidXQgSSBkb24ndCBy ZW1lbWJlciBpZiB0aGUgcHVibGljIHRyZWUgaGFzIFRodW1iLTIKPiBzdXBw b3J0Lgo+Cj4gLS0KPiBEYW5pZWwgSmFjb2Jvd2l0ego+IENvZGVTb3VyY2Vy eQo+Cg== >From gdb-patches-return-57599-listarch-gdb-patches=sources.redhat.com@sourceware.org Sat Aug 02 03:12:27 2008 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 23472 invoked by alias); 2 Aug 2008 03:12:27 -0000 Received: (qmail 23462 invoked by uid 22791); 2 Aug 2008 03:12:25 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 02 Aug 2008 03:12:04 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id A0BF317F43B for ; Fri, 1 Aug 2008 23:58:25 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m723C1lx4784220 for ; Sat, 2 Aug 2008 00:12:01 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m723Btnh007404 for ; Sat, 2 Aug 2008 00:11:56 -0300 Received: from [9.18.196.162] ([9.18.196.162]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m723Bt9r007254; Sat, 2 Aug 2008 00:11:55 -0300 Subject: Re: [PATCH-ppc 1/5] Add basic support for new VSX register set From: Thiago Jung Bauermann To: luisgpm@linux.vnet.ibm.com Cc: gdb-patches@sourceware.org In-Reply-To: <1217016940.29012.75.camel@gargoyle> References: <1217016940.29012.75.camel@gargoyle> Content-Type: text/plain Date: Sat, 02 Aug 2008 03:12:00 -0000 Message-Id: <1217646694.26214.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 Delivered-To: mailing list gdb-patches@sourceware.org X-SW-Source: 2008-08/txt/msg00022.txt.bz2 Content-length: 4758 On Fri, 2008-07-25 at 17:15 -0300, Luis Machado wrote: > This patch adds basic functionality for VSX registers as follows: > > * Adds pseudo-registers for VSX and Extended FPR's. > * Read/Write functions for pseudo-registers. > * Read/Write functions for VSxH registers. > * New ptrace definitions for GET_VSRREGS and SET_VSRREGS and calls to > fetch/store registers, in synch with the kernel. > * Defines numbering scheme for pseudo-registers. I'm no maintainer, but FWIW I reviewed and found only small issues. > +/* Supply register REGNUM in the VSX register set REGSET > + from the buffer specified by VSRREGS and LEN to register cache > + REGCACHE. If REGNUM is -1, do this for all registers in REGSET. */ > + > +void > +ppc_supply_vsxregset (const struct regset *regset, struct regcache *regcache, > + int regnum, const void *vsxregs, size_t len) > +{ > + struct gdbarch *gdbarch = get_regcache_arch (regcache); > + struct gdbarch_tdep *tdep; > + size_t offset = 0; This variable is always zero, so it's of no use. > +/* Collect register REGNUM in the VSX register set > + REGSET from register cache REGCACHE into the buffer specified by > + VSRREGS and LEN. If REGNUM is -1, do this for all registers in > + REGSET. */ > + > +void > +ppc_collect_vsxregset (const struct regset *regset, > + const struct regcache *regcache, > + int regnum, void *vsxregs, size_t len) > +{ > + struct gdbarch *gdbarch = get_regcache_arch (regcache); > + struct gdbarch_tdep *tdep; > + size_t offset = 0; Same here. > + static const char *const vsx_regs[] = { > + "vs0h", "vs1h", "vs2h", "vs3h", "vs4h", "vs5h", > + "vs6h", "vs7h", "vs8h", "vs9h", "vs10h", "vs11h", > + "vs12h", "vs13h", "vs14h", "vs15h", "vs16h", "vs17h", > + "vs18h", "vs19h", "vs20h", "vs21h", "vs22h", "vs23h", > + "vs24h", "vs25h", "vs26h", "vs27h", "vs28h", "vs29h", > + "vs30h", "vs31h", "vs32h" > + }; Maybe it's too late at night and I'm missing the obvious, but shouldn't it go only up to vs31h and not vs32h? > + for (i = 0; i < ppc_num_gprs; i++) > + valid_p &= tdesc_numbered_register (feature, tdesc_data, > + PPC_VSR0_UPPER_REGNUM + i, > + vsx_regs[i]); I don't think this loop should use ppc_num_gprs. Perhaps a new constant needs to be created? > static void > +supply_vsxregset (struct regcache *regcache, gdb_vsxregset_t *vsxregsetp) > +{ > + int i; > + struct gdbarch *gdbarch = get_regcache_arch (regcache); > + struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); > + int num_of_vsxregs = 32; This should be a constant. One more reason to create a ppc_num_vsx or somesuch (mmm... coming up with a good name for the constant is not that easy). > +/* Store one VSX register. */ > +static void > +store_vsx_register (const struct regcache *regcache, int tid, int regno) > +{ > + int ret; > + int offset = 0; This variable is not used. > static void > +fill_vsxregset (const struct regcache *regcache, gdb_vsxregset_t *vsxregsetp) > +{ > + int i; > + struct gdbarch *gdbarch = get_regcache_arch (regcache); > + struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); > + int num_of_vsxregs = 32; This should be a constant too. > /* Constants for register set sizes. */ > enum > { > - ppc_num_gprs = 32, /* 32 general-purpose registers */ > - ppc_num_fprs = 32, /* 32 floating-point registers */ > - ppc_num_srs = 16, /* 16 segment registers */ > - ppc_num_vrs = 32 /* 32 Altivec vector registers */ > + ppc_num_gprs = 32, /* 32 general-purpose registers. */ > + ppc_num_fprs = 32, /* 32 floating-point registers. */ > + ppc_num_srs = 16, /* 16 segment registers. */ > + ppc_num_vrs = 32, /* 32 Altivec vector registers. */ > + ppc_num_vsrs = 64, /* 64 VSX vector registers. */ > + ppc_num_efprs = 32 /* 32 Extended FP registers. */ > }; Why change the column of all the comments here? > /* Linux target descriptions. */ > extern struct target_desc *tdesc_powerpc_32l; > extern struct target_desc *tdesc_powerpc_altivec32l; > +extern struct target_desc *tdesc_powerpc_vsx32l; > extern struct target_desc *tdesc_powerpc_e500l; > extern struct target_desc *tdesc_powerpc_64l; > extern struct target_desc *tdesc_powerpc_altivec64l; > - > +extern struct target_desc *tdesc_powerpc_vsx64l; > #endif /* PPC_LINUX_TDEP_H */ I know this is very picky, but I'd preserve the blank line before #endif. -- []'s Thiago Jung Bauermann IBM Linux Technology Center