From: Andrew Cagney <ac131313@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] W.I.P. AltiVec ppc registers support.
Date: Sun, 02 Dec 2001 12:19:00 -0000 [thread overview]
Message-ID: <3C0A8CB8.9040504@cygnus.com> (raw)
In-Reply-To: <15370.29736.747589.390705@krustylu.cygnus.com>
> 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.''
next prev parent reply other threads:[~2001-12-02 20:19 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-28 18:09 Elena Zannoni
2001-11-18 13:27 ` Elena Zannoni
2001-11-18 14:11 ` Daniel Jacobowitz
2001-11-19 12:59 ` Andrew Cagney
2001-11-29 9:04 ` Andrew Cagney
2001-11-29 13:10 ` Daniel Jacobowitz
2001-11-19 16:00 ` Daniel Jacobowitz
2001-11-29 13:34 ` Kevin Buettner
2001-11-19 16:42 ` Kevin Buettner
2001-11-29 14:11 ` Kevin Buettner
2001-11-19 22:22 ` Kevin Buettner
2001-11-29 14:27 ` Elena Zannoni
2001-11-19 23:55 ` Elena Zannoni
2001-11-28 22:27 ` Daniel Jacobowitz
2001-12-02 10:28 ` Elena Zannoni
2001-12-02 12:19 ` Andrew Cagney [this message]
2001-12-02 14:59 ` Daniel Jacobowitz
2001-12-02 22:25 ` Andrew Cagney
2001-11-28 18:33 ` Daniel Jacobowitz
2001-11-18 13:40 ` Daniel Jacobowitz
2001-11-29 10:40 ` Kevin Buettner
2001-11-19 15:15 ` Kevin Buettner
2001-11-19 18:51 ` Elena Zannoni
2001-11-29 13:53 ` Elena Zannoni
2001-11-29 14:21 ` Kevin Buettner
2001-11-19 22:53 ` Kevin Buettner
2001-11-29 14:42 ` Elena Zannoni
2001-11-20 8:37 ` Elena Zannoni
2001-11-29 15:03 ` Andrew Cagney
2001-11-20 8:54 ` Andrew Cagney
2001-11-29 16:27 ` Kevin Buettner
2001-11-20 16:00 ` Kevin Buettner
2001-11-20 16:14 ` Andrew Cagney
2001-11-21 3:33 ` Daniel Jacobowitz
2001-11-29 17:41 ` Daniel Jacobowitz
2001-11-29 16:43 ` Andrew Cagney
2001-11-29 16:36 ` Elena Zannoni
2001-11-20 16:10 ` Elena Zannoni
2001-11-29 17:40 ` Daniel Jacobowitz
2001-11-20 18:00 ` Daniel Jacobowitz
2001-11-29 14:47 ` Daniel Jacobowitz
2001-11-20 8:37 ` Daniel Jacobowitz
2001-11-20 9:07 ` Kevin Buettner
2001-11-20 9:08 ` Andrew Cagney
2001-11-29 15:33 ` Andrew Cagney
2001-11-29 15:15 ` Kevin Buettner
2001-11-29 15:38 ` Daniel Jacobowitz
2001-11-20 9:13 ` Daniel Jacobowitz
2001-11-20 10:09 ` Kevin Buettner
2001-11-29 15:47 ` Kevin Buettner
2001-11-29 15:58 ` Andrew Cagney
2001-11-20 10:59 ` Andrew Cagney
2001-11-29 15:59 ` Daniel Jacobowitz
2001-11-20 11:07 ` Daniel Jacobowitz
2001-11-29 16:17 ` Andrew Cagney
2001-11-20 11:17 ` Andrew Cagney
2001-11-20 17:52 ` Daniel Jacobowitz
2001-11-29 17:39 ` Daniel Jacobowitz
2001-11-29 18:20 ` Andrew Cagney
2001-11-21 4:10 ` Andrew Cagney
2001-11-29 22:36 ` Daniel Jacobowitz
2001-11-21 5:56 ` Daniel Jacobowitz
2001-12-20 10:02 ` Elena Zannoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C0A8CB8.9040504@cygnus.com \
--to=ac131313@cygnus.com \
--cc=drow@mvista.com \
--cc=ezannoni@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox