This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa:ppc64] Fix 64-bit PPC ELF function calls
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Fri, 3 Oct 2003 14:22:31 -0700
- Subject: Re: [rfa:ppc64] Fix 64-bit PPC ELF function calls
- References: <3F6E368C.30009@redhat.com> <3F6F388D.5020706@redhat.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?
> > PS: Backtraces are a bit sick.
In what way?
> > 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?
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?
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?
Kevin