This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: AltiVec register ptrace support
- From: Jason R Thorpe <thorpej at wasabisystems dot com>
- To: Kumar Gala <kumar dot gala at motorola dot com>
- Cc: linuxppc-dev at lists dot linuxppc dot org,Daniel Jacobowitz <drow at mvista dot com>,Kevin Buettner <kevinb at redhat dot com>, gdb at sources dot redhat dot com,ezannoni at cygnus dot com, fsirl at kernel dot crashing dot org, paulus at samba dot org
- Date: Fri, 14 Dec 2001 11:16:20 -0800
- Subject: Re: AltiVec register ptrace support
- Organization: Wasabi Systems, Inc.
- References: <20011207173434.A28783@nevyn.them.org> <Pine.GSO.4.40.0112141249070.21737-100000@softail.somerset.sps.mot.com>
- Reply-to: thorpej at wasabisystems dot com
On Fri, Dec 14, 2001 at 12:52:33PM -0600, Kumar Gala wrote:
> Is there any reason that we can not spport both methods. There are
> applications in which having the ability to get all the registers is a
> single syscall is a major performance improvement.
I'll chime in...
Other systems that support ptrace(2) don't have PEEK/POKE/READ_U/WRITE_U
methods.
I'm currently working on AltiVec for NetBSD/powerpc, and ptrace(2) interface
for AltiVec is going to look like:
PT_GETALTIVECREGS
PT_SETALTIVECREGS
...both of which using the following structure as an argument:
struct vreg {
uint32_t vreg[32][4]; /* vector register contents */
register_t vscr; /* vector status and control reg */
register_t vrsave; /* SPR 238 */
};
This is consistent with how e.g. SSE/SSE2 registers are handled on
NetBSD/i386 (PT_GETXMMREGS/PT_SETXMMREGS).
--
-- Jason R. Thorpe <thorpej@wasabisystems.com>