This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] W.I.P. AltiVec ppc registers support.
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Elena Zannoni <ezannoni at cygnus dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>,gdb-patches at sources dot redhat dot com
- Date: Sun, 02 Dec 2001 15:19:04 -0500
- Subject: Re: [RFA] W.I.P. AltiVec ppc registers support.
- References: <email@example.com> <20011129012730.A19781@nevyn.them.org> <firstname.lastname@example.org>
> There is actually a patch posted at the beginning of September to
> which you replied at some stage. And this patch is similar to the one
> I have used for implementing GDB altivec support.
> The version of the patch I have was provided by Motorola, and they are
> about to submit it publicly. The patch is virtually identical to the
> one posted on linuxppc.org except for the definition of PT_VR0 which
> in the latter is (errouneously) made to be aligned on 128-bits. So
> for the patch I have PT_VR0 is simply PT_FPSCR + 1, not 128.
> My gdb implementation works also for machines w/o altivec ptrace
> support, because in that case the ptrace call just errors out and that
> condition is detected (I am talking about my original patch, w/o the
> changes that Kevin suggested). This was one objection to the kernel
> patch that I've seen raised on the linuxppc list.
> The thread subject is "AltiVec aware ptrace for Linux"
> and the original postings are on
> http://www.altivec.org/emailgroup follow the email archive link at the bottom of the page (this archive
> is a total pain to look through).
Nah, lets be honest, the web interface SUX - reminds us how lucky we are
with sources.redhat.com :-) Adding to this, it looks like the altivec
forum list rejects posts from people not on that list. To understand
the thread, you will need to read both lists and even then there appear
to be gaps. (You also want the thread ``AltiVec aware ptrace for
Linux'' and not the thread ``AltiVec aware version of ptrace for Linux''
on that server). Arrg.
Anyway, looks like the cat is out the bag!
While the published draft extension to PT_*USER might sux, it is rapidly
turning into a (poorly defined?) defacto standard. The extension is
also definitly consistent with the current interface and, as you
indicate, and contrary to several comments, does scale to support these
rumored AltiVec2 registers that people keep refering to.
Any reason why GDB shouldn't support the draft PT_*USER now and the
proposed (but non-existant) PT_*REGS later?
``The good thing about standards is that you've got so many to choose