Re: [rfa:ppc64] Fix 64-bit PPC ELF function calls

[Andrew Cagney <ac131313 at redhat dot com>]

> Sorry for not replying sooner.  I thought I had replied to this already...
>
> On Sep 22,  1:59pm, Andrew Cagney wrote:
>
>
> > > PS: The apparent bugs are:
> > > 
> > > - small odd structs get passed in memory instead of a register
> > >   (ref structs.exp:Fun3).
> > > - small even structs get passed right, instead of left, aligned in
> > >   the register (ref structs.exp:Fun[12]).
>
>
> These are all GCC bugs, right?  And, if they get fixed in GCC, then GDB
> will be broken?

Yes, as far as I know (but you would be wize to cross check my 
interpretation of the ABI).

No.  The patch gets around the problem thus:

+		      /* WARNING: cagney/2003-09-21: As best I can
+			 tell, the ABI specifies that the value should
+			 be left aligned.  Unfortunatly, GCC doesn't
+			 do this - it instead right aligns even sized
+			 values and puts odd sized values on the
+			 stack.  Work around that by putting both a
+			 left and right aligned value into the
+			 register (hopefully no one notices :-^).
+			 Arrrgh!  */

> > > PS: Backtraces are a bit sick.
>
>
> In what way?

They don't work.  All the backtrace tests I glanced at failed (and this 
is independant of the current fixes).

> > > PPS:  Oh, note the "hack" to find the TOC from the function's
> > >       entry point address.  Without it malloc() fails.
>
>
> Calls to other library functions would fail too.
>
> Is the TOC symbol name vs entry point name (i.e, FN vs..FN) convention
> mandated by the ABI, or is this something that's Linux specific?

It in the 64-bit ELF ABI.

> I notice some 80+ character lines in ppc64_sysv_abi_push_dummy_call().
> Could you adjust these so that they're 80 characters or less?

I'll run the file through gdb_indent.sh, as a separate commit.

> Also, a minor nit: in the comment...
>
>   /* Find a value for the TOC register.  Every symbol should have both
>      ".FN" and "FN" in the minimal symbol table.  "FN" points at the
>      F's descriptor, while ".FN" points at the entry point (which
>      matches FUNC_ADDR).  Need to reverse from FUNC_ADDR back to the
>      FN's descriptor address.  */
>
> ...at the beginning of the third line down, shouldn't that be:
>
>      FN's descriptor, [...]
>
> If not, what does `F' refer to?

It's a tipo, thanks.  The term "FN" is used in the ABI.

ok?
Andrew