From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14676 invoked by alias); 12 Sep 2005 20:32:33 -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 14651 invoked by uid 22791); 12 Sep 2005 20:32:26 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 12 Sep 2005 20:32:26 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EEuyS-0002qC-G2; Mon, 12 Sep 2005 16:32:20 -0400 Date: Mon, 12 Sep 2005 20:32:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: rth@twiddle.net, amodra@bigpond.net.au, gdb-patches@gcc.gnu.org Subject: Re: ppc32 debugging ppc64, part 1 Message-ID: <20050912203220.GA10796@nevyn.them.org> Mail-Followup-To: Mark Kettenis , rth@twiddle.net, amodra@bigpond.net.au, gdb-patches@gcc.gnu.org References: <20050912125047.GA5411@twiddle.net> <200509121947.j8CJlT1H030779@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509121947.j8CJlT1H030779@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00090.txt.bz2 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? 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. Hmm, this is a much cleaner way than I'd been using for MIPS n32. That bears some thinking about. -- Daniel Jacobowitz CodeSourcery, LLC