This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Fix powerpc64-linux inferior function calls
- From: Daniel Jacobowitz <drow at false dot org>
- To: David Lecomber <david at lecomber dot net>
- Cc: Alan Modra <amodra at bigpond dot net dot au>, gdb-patches at sources dot redhat dot com
- Date: Wed, 29 Mar 2006 19:05:37 -0500
- Subject: Re: Fix powerpc64-linux inferior function calls
- 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>
On Fri, Mar 03, 2006 at 11:23:40AM +0000, David Lecomber wrote:
> This stuff still appears to be broken!
Really?
> 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.
[dan@belgarath obj]$ ./gdb/gdb g
GNU gdb 6.4.50.20060329-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc64-unknown-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) start
Breakpoint 1 at 0x100004c0: file g.c, line 1.
Starting program: /scratch/dan/obj/g
main () at g.c:1
1 int main(){ }
(gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
$1 = (void *) 0x10011010
(gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
$2 = (void *) 0x10011030
(gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
$3 = (void *) 0x10011050
Looks like it works to me. This is a relatively old powerpc64-linux
installation; it uses dot symbols. malloc references the opd entry
rather than the function. Things seem to work.
(gdb) x/2gx &malloc
0x80911ba760 <malloc>: 0x00000080910d0a48 0x00000080911cb718
> Also, not sure what it's trying to tell me here (with latest CVS):
> (gdb) p (void* (*) (int))(&malloc)
> $7 = (void *(*)()) @0x80001ab870: 0x992e0
(gdb) p (void* (*) (int))(&malloc)
$4 = (void *(*)()) @0x80911ba760: 0x80910d0a48 <.malloc>
Sorry, but I can't reproduce your problem on the only powerpc64-linux
system I have access to.
--
Daniel Jacobowitz
CodeSourcery