From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30577 invoked by alias); 21 Feb 2002 05:04:50 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30407 invoked from network); 21 Feb 2002 05:04:46 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 21 Feb 2002 05:04:46 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id VAA03055; Wed, 20 Feb 2002 21:04:41 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.11.6/8.11.6) id g1L54NK00830; Wed, 20 Feb 2002 22:04:23 -0700 Date: Wed, 20 Feb 2002 21:04:00 -0000 From: Kevin Buettner Message-Id: <1020221050423.ZM829@localhost.localdomain> In-Reply-To: Elena Zannoni "Re: [RFA] ppc-linux-nat.c AltiVec regs ptrace" (Feb 20, 9:09pm) References: <15476.1308.919907.110811@localhost.redhat.com> <20020220153946.A24439@nevyn.them.org> <15476.4080.303671.894065@localhost.redhat.com> <20020220171519.A28726@nevyn.them.org> <15476.11279.326712.932158@localhost.redhat.com> <20020220184649.B7963@nevyn.them.org> <15476.16171.455269.862123@localhost.redhat.com> <20020220193446.A9812@nevyn.them.org> <15476.22212.358982.6179@localhost.redhat.com> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Elena Zannoni Subject: Re: [RFA] ppc-linux-nat.c AltiVec regs ptrace Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-02/txt/msg00586.txt.bz2 Elena, It looks pretty good. I noticed a typo in a comment. After your earlier remarks, I'm beginning to think that you put these in deliberately to see if I'd notice. ;-) There are a few things that I'm confused about though... On Feb 20, 9:09pm, Elena Zannoni wrote: > + time throuhg, and we have comfirmed that there is kernel ^^^^^^^ Here's the typo. Here's where I'm confused... > +static void > +supply_vrregset (gdb_vrregset_t *vrregsetp) > +{ > + int i; > + struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch); > + int num_of_vrregs = tdep->ppc_vrsave_regnum - tdep->ppc_vr0_regnum; Are you off by one here? I.e, shouldn't the above statement be int num_of_vrregs = tdep->ppc_vrsave_regnum - tdep->ppc_vr0_regnum + 1; ? > + int vrregsize = REGISTER_RAW_SIZE (tdep->ppc_vr0_regnum); > + int offset = vrregsize - REGISTER_RAW_SIZE (tdep->ppc_vrsave_regnum); > + > + for (i = 0; i < num_of_vrregs - 1; i++) Why ``num_of_vrregs - 1'' ? It seems to me that the combination of the fencepost error (above) combined with this one means that the last two Altivec registers won't get processed. > + { > + /* The last 2 registers of this set are only 32 bit long, not > + 128. However an offset is necessary only for VSCR because it > + occupies a whole vector, while VRSAVE occupies a full 4 bytes > + slot. */ > + if (i == (tdep->ppc_vrsave_regnum - 1)) > + supply_register (tdep->ppc_vr0_regnum + i, > + *vrregsetp + i * vrregsize + offset); > + else > + supply_register (tdep->ppc_vr0_regnum + i, *vrregsetp + i * vrregsize); > + } > +} [...] > static void > +fill_vrregset (gdb_vrregset_t *vrregsetp) > +{ > + int i; > + struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch); > + int num_of_vrregs = tdep->ppc_vrsave_regnum - tdep->ppc_vr0_regnum; I think this is another fencepost error. > + int vrregsize = REGISTER_RAW_SIZE (tdep->ppc_vr0_regnum); > + int offset = vrregsize - REGISTER_RAW_SIZE (tdep->ppc_vrsave_regnum); > + > + for (i = 0; i < num_of_vrregs; i++) This one looks right to me though, so long as you fix the computation of num_of_vrregs. Kevin