From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17144 invoked by alias); 3 Mar 2006 11:23:55 -0000 Received: (qmail 17135 invoked by uid 22791); 3 Mar 2006 11:23:54 -0000 X-Spam-Check-By: sourceware.org Received: from mta08-winn.ispmail.ntl.com (HELO mta08-winn.ispmail.ntl.com) (81.103.221.48) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 03 Mar 2006 11:23:52 +0000 Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35]) by mta08-winn.ispmail.ntl.com with ESMTP id <20060303112350.BJBQ29066.mta08-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>; Fri, 3 Mar 2006 11:23:50 +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 <20060303112349.PNWQ20857.aamta10-winn.ispmail.ntl.com@cpc2-oxfd8-0-0-cust771.oxfd.cable.ntl.com>; Fri, 3 Mar 2006 11:23:49 +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 k23BNeAf021691; Fri, 3 Mar 2006 11:23:42 GMT 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 Date: Fri, 03 Mar 2006 14:04:00 -0000 Message-Id: <1141385020.14575.71.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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/msg00071.txt.bz2 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