From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6579 invoked by alias); 2 Dec 2001 20:19:16 -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 6558 invoked from network); 2 Dec 2001 20:19:15 -0000 Received: from unknown (HELO localhost.cygnus.com) (24.114.42.213) by hostedprojects.ges.redhat.com with SMTP; 2 Dec 2001 20:19:15 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id AD05D3E19; Sun, 2 Dec 2001 15:19:04 -0500 (EST) Message-ID: <3C0A8CB8.9040504@cygnus.com> Date: Sun, 02 Dec 2001 12:19:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: Elena Zannoni Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [RFA] W.I.P. AltiVec ppc registers support. References: <15365.39495.801289.497931@krustylu.cygnus.com> <20011129012730.A19781@nevyn.them.org> <15370.29736.747589.390705@krustylu.cygnus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00018.txt.bz2 > 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.''