Re: Fix powerpc64-linux inferior function calls

[David Lecomber <david@lecomber.net>]

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>