From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28825 invoked by alias); 29 Nov 2001 21:34:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27763 invoked from network); 29 Nov 2001 21:33:03 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by hostedprojects.ges.redhat.com with SMTP; 29 Nov 2001 21:33:03 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA07097; Thu, 29 Nov 2001 13:32:58 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.9.3/8.9.3) id OAA19364; Thu, 29 Nov 2001 14:32:42 -0700 Date: Mon, 19 Nov 2001 16:42:00 -0000 From: Kevin Buettner Message-ID: <1011129213241.ZM19363@ocotillo.lan> In-Reply-To: Daniel Jacobowitz "Re: [RFA] W.I.P. AltiVec ppc registers support." (Nov 29, 4:09pm) References: <15365.39495.801289.497931@krustylu.cygnus.com> <20011129012730.A19781@nevyn.them.org> <3C066A96.6050201@cygnus.com> <20011129160916.A12345@nevyn.them.org> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [RFA] W.I.P. AltiVec ppc registers support. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-11/txt/msg00352.txt.bz2 Message-ID: <20011119164200.ilxZxrBEFPYBKPRFlqepSa5yold1c35eOfNN2zW3m9w@z> On Nov 29, 4:09pm, Daniel Jacobowitz wrote: > On Thu, Nov 29, 2001 at 12:04:22PM -0500, Andrew Cagney wrote: > > > > > >Wait, I knew I was forgetting something important. > > > > > >There is no kernel support for this feature in any public PowerPC > > >kernel tree, and to my knowledge there has been no suggested patch for > > >it on any of the public LinuxPPC forums. As such, the interface to it > > >is still up in the air. I've discussed this with other kernel folk at > > >various times, and the general consensus is that, instead of adding > > >them to the user area and using PEEKUSR, someone should simply > > >implement PTRACE_GETFPXREGS (perhaps just PTRACE_GETXREGS, as the FP > > >does not really apply, but consistency...). We almost never want to > > >fetch just one altivec register, excepting maybe VRSAVE, and GETFPXREGS > > >takes negligibly more time than a single PEEKUSR call. > > > > So if the tweek to ppc-linux-nat.c that does the register fetch was > > omitted, it would be ok? > > It would be (somewhat trivial, but) OK, yes. I have nothing against > the implementation, just the interface. If Elena makes the changes that I have in mind, the AltiVec specific code which affects the interface will collapse down to 5 lines or so. Of course, if PTRACE_GETFPXREGS (or the like) ends up being used, ppc-linux-nat.c need to be substantially rewritten anyway. But the point is that the five lines (or so) that I have in mind can then just be deleted. Kevin