This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bogus PPC64 return-colum? Was: [Fwd: Re: [PATCH] S/390 DWARF-2 CFI frame support]
- From: Mark Kettenis <kettenis at chello dot nl>
- To: amodra at bigpond dot net dot au
- Cc: cagney at redhat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 1 Jan 2004 14:24:08 +0100 (CET)
- Subject: Re: Bogus PPC64 return-colum? Was: [Fwd: Re: [PATCH] S/390 DWARF-2 CFI frame support]
- References: <3FF328F7.2070205@gnu.org> <20040101110125.GB26668@bubble.sa.bigpond.net.au>
Date: Thu, 1 Jan 2004 21:31:25 +1030
From: Alan Modra <amodra@bigpond.net.au>
PPC64 (and PPC32) GCC currently ignores the DWARF register numbering,
and instead just uses the internal GCC numbering. It's easy to fix,
except that we need some ABI doco changes to accommodate GCC's splitting
of cr into fields, but once fixed we run into the problem of what to do
about current binaries. Is it worth hacking gdb to support them?
I don't think it is worth it. The current GCC mapping and the DWARF
mapping specified by the System V use the same register numbers for
%r0-%r31 and %f0-%f31. For most of the other registers, I've created
a table that comparses GCC with current GDB and the System V DWARF
numbering:
# GCC GDB SysV
64 mq pc cr
65 lr ps fpsr
66 ctr cr ps
67 ap lr -
68 cr0 ctr -
69 cr1 xer -
70 cr2 fpscr sr0
71 cr3 %v0 ...
72 cr4 ... ...
73 cr5 ... ...
74 cr6 ... ...
75 cr7 ... ...
76 xer ... ...
77 %v0 ... ...
.. ... ... ...
85 ... ... sr15
.. ... ... -
100 ... ... mq
101 ... ... xer
102 ... %v31 -
.. ... - -
104 ... vrsave -
.. ... - -
108 %v31 - lr
109 - - ctr
124 - mq -
We see that GDB doesn't follow the current GCC mapping. For stabs
things are fixed up for mq, lr, ctr and xer (not for the other
registers) but not for DWARF. I doubt that GCC is emitting these
register numbers in its debug info anyway. Except for AltiVec of
course, and possibly ap. The lr register is used in DWARF CFI (and
therefore in the unwind info used for exception handling), but there
its location is explicitly encoded in the CFI itself.
So at first sight it might be possible to fix GCC without too much
impact. Your concerns about GCC's splitting of cr are probably
unnecessary since I can't imagine these ending up in the DWARF debug
info.
Note that I'm not really familiar with the PowerPC architecture, so
someone should probably take a closer look, especially how this
influences the ABI compatibility with respect to exception handling.
Mark