From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32004 invoked by alias); 21 Feb 2002 15:39:35 -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 31875 invoked from network); 21 Feb 2002 15:39:31 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 21 Feb 2002 15:39:31 -0000 Received: from localhost.redhat.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA04612; Thu, 21 Feb 2002 07:39:17 -0800 (PST) Received: by localhost.redhat.com (Postfix, from userid 469) id 7291811403; Thu, 21 Feb 2002 10:39:09 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15477.5277.320949.685078@localhost.redhat.com> Date: Thu, 21 Feb 2002 07:39:00 -0000 To: Kevin Buettner Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] ppc-linux-nat.c AltiVec regs ptrace In-Reply-To: <1020221153240.ZM2943@localhost.localdomain> References: <15476.1308.919907.110811@localhost.redhat.com> <1020221153240.ZM2943@localhost.localdomain> X-Mailer: VM 7.00 under Emacs 20.7.1 X-SW-Source: 2002-02/txt/msg00593.txt.bz2 Kevin Buettner writes: > On Feb 20, 3:20pm, Elena Zannoni wrote: > > > There are 32 vector registers 16 bytes longs, plus a VSCR register > > which is only 4 bytes long, but is fetched as a 16 bytes quantity. Up > > to here we have the elf_vrregset_t structure. > > Appended to this there is space for the VRSAVE register: 4 bytes. > > Even though this vrsave register is not included in the regset > > typedef, it is handled by the ptrace requests. > > > > The layout is like this: > > > > |.|.|.|.|.....|.|.|.|.||.|.|.|x||.| > > <-------> <-------><-------><-> > > VR0 VR31 VSCR VRSAVE > > (where x is the actual value of the vscr reg) > > Could you add these remarks and this picture as a comment to > ppc-linux-nat.c? I found it really useful when reviewing parts of the > code. In particular, I found it useful when looking over the > following function... > Yes, good idea. > > > +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; > > + 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++) > > + { > > + /* 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); > > + } > > +} > > I have a question regarding the treatment of VSCR. Will the offset > that you computed be correct when running on a little endian machine? > This may be unanswerable, because it'll likely depend upon what the > ptrace() implementation does. Therefore, I'm not necessarily > suggesting that you change your patch, but do give it a moment or two of > thought... > Yes, I thought about this, I could compute a different offset. But I'll ask the ptrace implementor... Is there such a piece of hardware? I guess I'll add a comment in there, pointing out the endiannes problem. Elena > Kevin