Re: Fix powerpc64-linux inferior function calls

[David Lecomber <david@lecomber.net>]

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

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  <dan@codesourcery.com>
           Ulrich Weigand  <uweigand@de.ibm.com>

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 <david@lecomber.net>


#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

[-- Attachment #2: Attached message - Re: Fix powerpc64-linux inferior function calls --]
[-- Type: message/rfc822, Size: 3169 bytes --]

From: David Lecomber <david@lecomber.net>
To: Alan Modra <amodra@bigpond.net.au>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Fix powerpc64-linux inferior function calls
Date: Fri, 03 Mar 2006 11:23:47 +0000
Message-ID: <1141385020.14575.71.camel@localhost.localdomain>

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 <malloc>:  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 <david@lecomber.net>