From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31971 invoked by alias); 18 Sep 2005 02:14: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 30979 invoked by uid 22791); 18 Sep 2005 02:13:36 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 18 Sep 2005 02:13:36 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EGogN-0000b7-R4; Sat, 17 Sep 2005 22:13:31 -0400 Date: Sun, 18 Sep 2005 02:14:00 -0000 From: Daniel Jacobowitz To: Richard Henderson Cc: amodra@bigpond.net.au, gdb-patches@gcc.gnu.org Subject: Re: ppc32 debugging ppc64, part 1 Message-ID: <20050918021331.GA2134@nevyn.them.org> Mail-Followup-To: Richard Henderson , amodra@bigpond.net.au, gdb-patches@gcc.gnu.org References: <20050912125047.GA5411@twiddle.net> <20050917212403.GF8777@nevyn.them.org> <20050918020123.GA1389@twiddle.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050918020123.GA1389@twiddle.net> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00149.txt.bz2 On Sat, Sep 17, 2005 at 07:01:23PM -0700, Richard Henderson wrote: > On Sat, Sep 17, 2005 at 05:24:03PM -0400, Daniel Jacobowitz wrote: > > You don't need this; PTRACE_TYPE_RET should work OK. We get that from > > autoconf (even if the autoconf bits are a bit broken on Linux at the > > moment, they'll choose long anyway). > > I've purged PTRACE_XFER_TYPE from the file entirely. Thanks. > > I think it's safe to do away with the syscalls; the current userspace > > ptrace interface where glibc has to special-case PEEKTEXT/PEEKDATA/PEEKUSER > > is nasty enough, so I'm willing to declare glibc broken if it is ever > > "fixed" to handle the PEEK*_3264 operations specially. > > What about the argument that it causes source uglification because > PEEKUSER and PEEKUSER_3464 have different calling sequences in the > libc funtion, but not the syscall? > > For the record, my current source follows. > > I'll get rid of the use of the syscall if required, but my 2 cents > say it looks cleaner this way. Yes, that's a more compelling argument. Works for me. -- Daniel Jacobowitz CodeSourcery, LLC