This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] W.I.P. AltiVec ppc registers support.



> 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"
> 
> http://lists.linuxppc.org/linuxppc-dev/200109/msg00029.html
> 
> 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?

enjoy,
Andrew

``The good thing about standards is that you've got so many to choose 
from.''



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]