This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Incorrect DWARF-2 register numbers on PPC64?
- From: Andrew Cagney <cagney at gnu dot org>
- To: Mark Kettenis <kettenis at chello dot nl>, dje at watson dot ibm dot com
- Cc: gcc at gcc dot gnu dot org, gdb-patches at sources dot redhat dot com,Ulrich dot Weigand at de dot ibm dot com, geoffk at geoffk dot org
- Date: Fri, 02 Jan 2004 11:46:33 -0500
- Subject: Re: Incorrect DWARF-2 register numbers on PPC64?
- References: <OFEA5CA921.302AEEB5-ON41256E00.005FB141@de.ibm.com> <200312182258.hBIMwgT25422@makai.watson.ibm.com> <200312201527.hBKFRHgI000712@elgar.kettenis.dyndns.org>
Date: Thu, 18 Dec 2003 17:58:42 -0500
From: David Edelsohn <dje@watson.ibm.com>
>>>>> Andrew Cagney writes:
> Argh! Someone teach GCC about the PPC64 DWARF register numbering
> please! Before it is too late! Now it is using the PPC32 LR register
> number, which just happens to be the PPC64 FPSCR register.
The 32-bit PowerPC System V ABI defines DWARF Register Number
Mapping that does not appear to be implemented in GCC or GDB. This issue
probably requires more thought and discussion about whether PPC64 should
be compatible with PPC32 or PPC64 should be compliant with the ABI or both
PPC32 and PPC64 should be compliant with the ABI.
Ah, You're right. I should have looked a little better. So currently
GCC uses the same mapping for DWARF as it does for stabs. Seems like
there is a problem with GDB; we do some remapping for stabs (see
rs6000-tdep.c:rs6000_stab_reg_to_regnum), but don't remap for DWARF.
We probably should at least fix that until things are cleared up.
I'd ignore GDB here. I think GCC, for the 64-bit SvR4 PPC ABI, should
use the correct numbers. If that means GDB tweaks, so be it.
Personally I find it a bit awkward to use a non-standard register
mapping if there is a mapping defined in the ABI, so I'm in favour of
using the mapping defined in the System V ABI. I don't know if this
is possible though, since changing the mapping might break exception
handling[1].
Mark
[1] From casual inspection this doesn't seem to be the case. The
general purpose registers will still be mapped in the same way, and
the return address column is encoded in the debug info itself.