From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1997 invoked by alias); 3 Mar 2006 13:51:26 -0000 Received: (qmail 1986 invoked by uid 22791); 3 Mar 2006 13:51:25 -0000 X-Spam-Check-By: sourceware.org Received: from mta07-winn.ispmail.ntl.com (HELO mta07-winn.ispmail.ntl.com) (81.103.221.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 03 Mar 2006 13:51:22 +0000 Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20060303135112.PYJB15056.mta07-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>; Fri, 3 Mar 2006 13:51:12 +0000 Received: from cpc2-oxfd8-0-0-cust771.oxfd.cable.ntl.com ([80.6.83.112]) by aamta10-winn.ispmail.ntl.com with ESMTP id <20060303135112.SABB20857.aamta10-winn.ispmail.ntl.com@cpc2-oxfd8-0-0-cust771.oxfd.cable.ntl.com>; Fri, 3 Mar 2006 13:51:12 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by cpc2-oxfd8-0-0-cust771.oxfd.cable.ntl.com (8.13.4/8.13.4) with ESMTP id k23Dp8qc022586; Fri, 3 Mar 2006 13:51:10 GMT Subject: Re: Fix powerpc64-linux inferior function calls From: David Lecomber To: dan@codesourcery.com Cc: gdb-patches@sources.redhat.com In-Reply-To: <1141385020.14575.71.camel@localhost.localdomain> References: <20050928073345.GK29044@bubble.grove.modra.org> <20051002223118.GC32728@nevyn.them.org> <20051002232228.GB26007@bubble.grove.modra.org> <20051002234834.GA4773@nevyn.them.org> <20051003003506.GC26007@bubble.grove.modra.org> <20051003010437.GA6497@nevyn.them.org> <20051003033223.GD26007@bubble.grove.modra.org> <20051003044041.GA10992@nevyn.them.org> <20051003081957.GF26007@bubble.grove.modra.org> <1141385020.14575.71.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-yZgHR3YIGrNUdmDnBqM8" Date: Fri, 03 Mar 2006 14:11:00 -0000 Message-Id: <1141393868.14575.91.camel@localhost.localdomain> Mime-Version: 1.0 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00072.txt.bz2 --=-yZgHR3YIGrNUdmDnBqM8 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 2053 Hi Dan, I think this one arrived with your mega-change in September. I've binary searched it to the diffs you made on 2005-09-10: 2005-09-10 Daniel Jacobowitz Ulrich Weigand When debugging it, as I said before, I really didn't believe the output from where ppp64_linux_convert_from_func_ptr_addr attempted to read from the address of that function pointer.. (stack is after my .sig..) but that is also the point at which my subject knowledge is exhausted. -- David Lecomber #0 xfer_memory (memaddr=549757565040, myaddr=0x1ffffffcd70 "", len=8, write=0, attrib=0x0, target=0x104965c8) at /tmp/david/gdb-6.3.50.20051116/gdb/exec.c:477 #1 0x0000000010172948 in default_xfer_partial (ops=0x104965c8, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x1ffffffcd70 "", writebuf=0x0, offset=549757565040, len=8) at /tmp/david/gdb-6.3.50.200 51116/gdb/target.c:1321 #2 0x0000000010171758 in target_xfer_partial (ops=0x104965c8, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x1ffffffcd70, writebuf=0x0, offset=549757565040, len=8) at /tmp/david/gdb-6.3.50.2005111 6/gdb/target.c:863 #3 0x0000000010172a80 in target_read_partial (ops=0x104965c8, object=TARGET_OBJECT_MEMORY, annex=0x0, buf=0x1ffffffcd70 "", offset=549757565040, len=8) at /tmp/david/gdb-6.3.50.20051116/gdb/target.c: 1351 #4 0x0000000010172bc4 in target_read (ops=0x104965c8, object=TARGET_OBJECT_MEMORY, annex=0x0, buf=0x1ffffffcd70 "", offset=549757565040, len=8) at /tmp/david/gdb-6.3.50.20051116/gdb/target.c:1373 #5 0x0000000010172e00 in get_target_memory (ops=0x104965c8, addr=549757565040, buf=0x1ffffffcd70 "", len=8) at /tmp/david/gdb-6.3.50.20051116/gdb/target.c:1414 #6 0x0000000010172eb0 in get_target_memory_unsigned (ops=0x104965c8, addr=549757565040, len=8) at /tmp/david/gdb-6.3.50.20051116/gdb/target.c:1426 #7 0x0000000010078220 in ppc64_linux_convert_from_func_ptr_addr (gdbarch=0x1052dfb0, addr=549757565040, targ=0x104965c8) at /tmp/david/gdb-6.3.50.20051116/gdb/ppc-linux-tdep.c:801 --=-yZgHR3YIGrNUdmDnBqM8 Content-Disposition: inline Content-Description: Attached message - Re: Fix powerpc64-linux inferior function calls Content-Type: message/rfc822 Content-length: 3149 Subject: Re: Fix powerpc64-linux inferior function calls From: David Lecomber To: Alan Modra Cc: gdb-patches@sources.redhat.com In-Reply-To: <20051003081957.GF26007@bubble.grove.modra.org> References: <20050928073345.GK29044@bubble.grove.modra.org> <20051002223118.GC32728@nevyn.them.org> <20051002232228.GB26007@bubble.grove.modra.org> <20051002234834.GA4773@nevyn.them.org> <20051003003506.GC26007@bubble.grove.modra.org> <20051003010437.GA6497@nevyn.them.org> <20051003033223.GD26007@bubble.grove.modra.org> <20051003044041.GA10992@nevyn.them.org> <20051003081957.GF26007@bubble.grove.modra.org> Content-Type: text/plain Message-Id: <1141385020.14575.71.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Date: Fri, 03 Mar 2006 11:23:47 +0000 X-Evolution-Format: text/plain X-Evolution-Account: 1082107212.8206.1@cpc3-oxfd3-6-0-cust40.oxfd.cable.ntl.com X-Evolution-Transport: smtp://david@localhost X-Evolution-Fcc: email://local@local/Sent Content-Transfer-Encoding: 7bit Content-length: 2071 Hi Alan, and all, On Mon, 2005-10-03 at 17:49 +0930, Alan Modra wrote: > On Mon, Oct 03, 2005 at 12:40:41AM -0400, Daniel Jacobowitz wrote: > > Thanks! I've no strong preference between the patches (mine minus the > > BSF_GLOBAL hack) now. > > I prefer yours. This stuff still appears to be broken! A tarball I have from mid-June 20050615 works fine, recent CVS does not and certainly back in November 20051116 did not work. Take a simple C code.. int main(){ } Compile "gcc -m64 -g" This GDB was configured as "powerpc64-unknown-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1". (gdb) b main Breakpoint 1 at 0x100004f0: file hello.c, line 4. (gdb) r Starting program: /tmp/david/gdb-6.3.50.20051116/a.out Breakpoint 1, main () at hello.c:4 4 } (gdb) p (((void* (*) (int)) &malloc) (sizeof(int))) Program received signal SIGSEGV, Segmentation fault. 0x00000000000992e0 in ?? () The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (at 0x992e0) will be abandoned. But back in June, life was far far sweeter: (gdb) p (((void* (*) (int)) &malloc) (sizeof(int))) $1 = (void *) 0x10011010 All that casting stuff seemed to make it work in those days. It believes malloc to have size 4, being an unknown thing, so a bit of fudgery was letting us get the 8 byte address and call that.. >From some debugging of the new GDB, it looks like ppp64_linux_convert_from_func_ptr_addr is returning something garbagey.. 0x992e0.. Also, not sure what it's trying to tell me here (with latest CVS): (gdb) p (void* (*) (int))(&malloc) $7 = (void *(*)()) @0x80001ab870: 0x992e0 Yet.. (gdb) x /4 0x80001ab870 0x80001ab870 : 0x00000080 0x000e52e0 0x00000080 0x001bd748 -- and I think the true entry point of malloc should be 0x00000080000e52e or near enough.. Any hints about this appreciated.. d. -- David Lecomber --=-yZgHR3YIGrNUdmDnBqM8--