Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: eliz@is.elta.co.il, gdb@sources.redhat.com
Subject: Re: i386 register numbering
Date: Sat, 28 Jul 2001 10:41:00 -0000	[thread overview]
Message-ID: <200107281741.f6SHfoN19109@delius.kettenis.local> (raw)
In-Reply-To: <3B62D68B.6010401@cygnus.com>

   Date: Sat, 28 Jul 2001 11:13:15 -0400
   From: Andrew Cagney <ac131313@cygnus.com>

   They map a stab/dwarf/... reg onto a cooked regnum (not to be confused 
   with a raw reg found in the register cache).  Because the i386 
   implements its registers using the old PSUEDO / CONVERT stuff, the 
   importance of differentiating between the two may not be obvious.

For most of the registers on the i386, the raw and the cooked regnum
will probably be the same.  MMX will probably end up as a cooked
registers some day (since they provide a different view on the
standard FP registers).  I cannot see how I can get rid of the convert
stuff for the FP registers though.  On the i386 the FP registers can
contain a `float', `double' or `long double' but the internal
representation in the FP register is identical.  Turning every FP
register into three cooked registers won't work since in the debug
info they will all have the same register number :-(.

   There is something here I don't get either.

   At present it is assumed that, for a given ISA/ABI, there is only one 
   mapping from a DEBUG reg to a REGNUM.  I take it, Mark, that you're 
   saying that in reality, the mapping depends on all of:

   {compiler, object format, debug format, ISA/ABI} (debug reg) -> REGNUM

   True? Ulgh!

That's another way to put it.  Note that GDB allows for different
mappings for each debug format.  When we go multi-arch, we can easily
differentiate by object format too just like for ISA/ABI.  The only
compiler that I have access to is GCC, so I don't know whether there
are other compilers out there that use different numbering schemes.
However, since there doesn't seem to be any standard, I suspect that
they will, at least for the FP, SSE and MMX registers.

We can probably deal with all these differences.  It just means a bit
more work :-(.

Mark




  reply	other threads:[~2001-07-28 10:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-28  3:14 Eli Zaretskii
2001-07-28  4:56 ` Mark Kettenis
2001-07-28  5:14   ` Eli Zaretskii
2001-07-28  8:12     ` Andrew Cagney
2001-07-28 10:41       ` Mark Kettenis [this message]
2001-07-28 11:06         ` Andrew Cagney
2001-07-28 15:02           ` Mark Kettenis
2001-07-28 18:06             ` Andrew Cagney
2001-07-28 11:02     ` 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=200107281741.f6SHfoN19109@delius.kettenis.local \
    --to=kettenis@wins.uva.nl \
    --cc=ac131313@cygnus.com \
    --cc=eliz@is.elta.co.il \
    --cc=gdb@sources.redhat.com \
    /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