From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23055 invoked by alias); 21 Feb 2002 15:33:07 -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 22691 invoked from network); 21 Feb 2002 15:32:57 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 21 Feb 2002 15:32:57 -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 HAA03909; Thu, 21 Feb 2002 07:32:52 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.11.6/8.11.6) id g1LFWeq02944; Thu, 21 Feb 2002 08:32:40 -0700 Date: Thu, 21 Feb 2002 07:33:00 -0000 From: Kevin Buettner Message-Id: <1020221153240.ZM2943@localhost.localdomain> In-Reply-To: Elena Zannoni "[RFA] ppc-linux-nat.c AltiVec regs ptrace" (Feb 20, 3:20pm) References: <15476.1308.919907.110811@localhost.redhat.com> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] ppc-linux-nat.c AltiVec regs ptrace MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-02/txt/msg00592.txt.bz2 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... > +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... Kevin