From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14675 invoked by alias); 12 Sep 2005 21:20:26 -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 14421 invoked by uid 22791); 12 Sep 2005 21:19:51 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 12 Sep 2005 21:19:51 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id j8CLJERY014250; Mon, 12 Sep 2005 23:19:14 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j8CLJDSc001551; Mon, 12 Sep 2005 23:19:13 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j8CLJDNE020689; Mon, 12 Sep 2005 23:19:13 +0200 (CEST) Date: Mon, 12 Sep 2005 21:20:00 -0000 Message-Id: <200509122119.j8CLJDNE020689@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: mark.kettenis@xs4all.nl, rth@twiddle.net, amodra@bigpond.net.au, gdb-patches@gcc.gnu.org In-reply-to: <20050912203220.GA10796@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 12 Sep 2005 16:32:20 -0400) Subject: Re: ppc32 debugging ppc64, part 1 References: <20050912125047.GA5411@twiddle.net> <200509121947.j8CJlT1H030779@elgar.sibelius.xs4all.nl> <20050912203220.GA10796@nevyn.them.org> X-SW-Source: 2005-09/txt/msg00093.txt.bz2 > Date: Mon, 12 Sep 2005 16:32:20 -0400 > From: Daniel Jacobowitz > > On Mon, Sep 12, 2005 at 09:47:29PM +0200, Mark Kettenis wrote: > > Hmm, this is really odd. From what I see above and the changes to the > > code you made, the implementation of ptrace seems to be just plain > > broken, either in the kernel or in glibc, probably both. > > > > Anyway, I'd really like to see people moving away from using > > PTRACE_XFER_TYPE and PTRACE_ARG3_TYPE in favour of PTRACE_TYPE_RET and > > PTRACE_TYPE_ARG3. I wouldn't be surprised if it became clear what's > > wrong with ptrace(2) on Linux ppc if you realize that PTRACE_XFER_TYPE > > really is the return type of ptrace(2). > > > > This code really should be using PTRACE_GETREGS and friends (like you > > indicate in the patch) but those are not implemented I assume? > > > > I'd really wish this would be fixed in the kernel, instead of being > > worked around in GDB :-(. > > Mark, you seem to be very big on assuming GNU/Linux systems are broken; > I'm sensing a real recurring theme here. Could you explain exactly > what it is that you think is broken now? >From Richards patch I inferred that the prototype for ptrace(2) doesn't actually match the actual system call in some cases. That's bad. But I may be wrong here... ...but in that case Richard is making things hopelessly complicated by doing using syscall() instead of ptrace(). > Richard's trying to do something fairly different from GDB's ordinary > usage model of ptrace here. PTRACE_PEEKDATA_3264 allows a 32-bit > process to request four bytes of memory from the inferior by specifying > a full 64-bit address. If I'm reading it right, it does this by > passing the address by reference, instead of in arg3. Similarly > there's a way to read the 64-bit registers in two different 32-bit > pieces. Fair enough. But this code is really getting difficult to read. It uses several constructs that really only made sense in the generic code where this was copied from. What really frustrates me is that the different Linux ports are reinventing the wheel, all in a different way. There are several architectures that have the same 32x64 issues, yet there's nobody who steps back, notices the pattern, and tries to solve the problem in a unified way. This makes us end up with a lot of native-dependent code that's really hard to maintain. Mark