public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: mark.kettenis@xs4all.nl (Mark Kettenis)
Cc: randolph@tausq.org, gdb@sources.redhat.com, brobecker@adacore.com
Subject: Re: Register numbers on hppa64
Date: Sat, 26 Nov 2005 18:50:00 -0000	[thread overview]
Message-ID: <200511261831.jAQIVckq014731@hiauly1.hia.nrc.ca> (raw)
In-Reply-To: <200511261719.jAQHJnTd015739@elgar.sibelius.xs4all.nl> from "Mark Kettenis" at Nov 26, 2005 06:19:49 pm

> It looks like we need some
> GCC_DEVELOPERS_DONT_THINK_BEFORE_THEY_CODE_MAP_REG_TO_REGNUM mapping.
> (sorry Dave) Sigh....
~

> > I wrote that code... :) but I think it's actually wrong; for 32-bit we 
> > have a 1:1 mapping between what gcc outputs for "dbx" register numbers 
> > in dwarf debug mode and the gdb internal register numbering, so we 
> > shouldn't need this mapping function for 32-bit.
> 
> No, even for 32-bit stuff there is a mapping:
> 
> /* How to renumber registers for dbx and gdb.
> 
>    Registers 0  - 31 remain unchanged.
> 
>    Registers 32 - 87 are mapped to 72 - 127
> 
>    Register 88 is mapped to 32.  */
> 
> But you're right, it's not right to use this encoding for decoding
> DWARF CFI since that uses the a different mapping (but that mapping
> isn't 1:1).

I believe that we have a 1:1 mapping between gcc's frame and dbx
numbers at the moment.  I haven't fully thought this through but
the save state contains information that we don't currently
copy to the frame state.  We could record this frame state data
if there was a way to restore it.  Thus, I don't believe that
gcc's sets of frame and dbx registers have to be the same.  For
example, there is no direct way in gcc to set the floating point
status registers.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

  reply	other threads:[~2005-11-26 18:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200511260253.jAQ2rP7Z021130@hiauly1.hia.nrc.ca>
2005-11-26  9:23 ` Randolph Chung
2005-11-26 15:54   ` Mark Kettenis
2005-11-26 16:52     ` Randolph Chung
2005-11-26 17:32       ` Mark Kettenis
2005-11-26 18:50         ` John David Anglin [this message]
2005-11-27 16:30         ` Randolph Chung
2005-11-26 17:34       ` John David Anglin
2005-11-26 17:20     ` John David Anglin
2005-11-26 17:13   ` John David Anglin
2005-11-26 17:52     ` Mark Kettenis
2005-11-26 18:00       ` John David Anglin
2005-11-26 18:31         ` Mark Kettenis
2005-11-27  4:30           ` John David Anglin
2005-11-27 15:10             ` Randolph Chung
2005-11-27 16:52               ` John David Anglin
2005-11-27 17:42               ` 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=200511261831.jAQIVckq014731@hiauly1.hia.nrc.ca \
    --to=dave@hiauly1.hia.nrc.ca \
    --cc=brobecker@adacore.com \
    --cc=gdb@sources.redhat.com \
    --cc=mark.kettenis@xs4all.nl \
    --cc=randolph@tausq.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).