From: Mark Kettenis <kettenis@chello.nl>
To: dje@watson.ibm.com
Cc: cagney@gnu.org, gcc@gcc.gnu.org, gdb-patches@sources.redhat.com,
Ulrich.Weigand@de.ibm.com, geoffk@geoffk.org
Subject: Re: Incorrect DWARF-2 register numbers on PPC64?
Date: Sat, 20 Dec 2003 15:27:00 -0000 [thread overview]
Message-ID: <200312201527.hBKFRHgI000712@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <200312182258.hBIMwgT25422@makai.watson.ibm.com> (message from David Edelsohn on Thu, 18 Dec 2003 17:58:42 -0500)
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.
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.
next prev parent reply other threads:[~2003-12-20 15:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <OFEA5CA921.302AEEB5-ON41256E00.005FB141@de.ibm.com>
2003-12-18 22:58 ` David Edelsohn
2003-12-20 15:27 ` Mark Kettenis [this message]
2004-01-02 16:46 ` Andrew Cagney
2004-01-02 23:18 ` Geoff Keating
2004-01-06 15:27 ` Alan Modra
[not found] ` <amodra@bigpond.net.au>
2004-01-06 16:02 ` David Edelsohn
2004-01-06 18:07 ` Geoff Keating
2004-01-06 18:10 ` David Edelsohn
2004-01-06 22:05 ` Geoff Keating
2004-01-06 22:09 ` David Edelsohn
2004-01-06 22:34 ` Geoff Keating
2004-01-07 0:27 ` Alan Modra
2004-01-07 17:43 ` Mark Kettenis
2004-01-07 22:29 ` Alan Modra
2004-01-07 23:36 ` Andrew Cagney
2004-01-08 0:48 ` Alan Modra
2004-01-08 5:02 ` Geoff Keating
2004-01-09 2:34 ` Alan Modra
2004-01-09 2:49 ` Alan Modra
2004-01-09 6:39 ` Alan Modra
2004-01-09 15:16 ` Mark Kettenis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200312201527.hBKFRHgI000712@elgar.kettenis.dyndns.org \
--to=kettenis@chello.nl \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=cagney@gnu.org \
--cc=dje@watson.ibm.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=geoffk@geoffk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox