i386 register numbering

i386 register numbering

[Eli Zaretskii]

Consider the following program:

#include <stdio.h>

double one = 1.0;

int main (void)
{
  double d;

  d = 2.0*one;
  printf ("%f\n", d);
  return 0;
}

Now observe:

  gcc -g -O -o ftest.exe ftest.c
  gdb ftest.exe
  (gdb) break 10
  Breakpoint 1 at 0x15fe: file ftest.c, line 10
  (gdb) run
  Starting program: ftest.exe

  Breakpoint 1, main () at ftest.c:10
  10	printf ("%f\n", d);
  (gdb) info address d
  Symbol "d" is a variable in register ds.

In fact, `d' is in st(0), of course.

This happens because the numbering of registers used by GCC differs
from the one used by GDB, see gcc/config/i386/i386.h in the GCC
distribution.  Since i386.h seems to be common for all i386 targets,
I'd expect this problem to pop up on other x86 targets as well (the
above was tested with DJGPP native debugging).

Do others indeed see this bug?  If so, what would be the best way of
fixing it?

Re: i386 register numbering

[Mark Kettenis]

Eli Zaretskii <eliz@delorie.com> writes:

> This happens because the numbering of registers used by GCC differs
> from the one used by GDB, see gcc/config/i386/i386.h in the GCC
> distribution.  Since i386.h seems to be common for all i386 targets,
> I'd expect this problem to pop up on other x86 targets as well (the
> above was tested with DJGPP native debugging).
> 
> Do others indeed see this bug?  If so, what would be the best way of
> fixing it?

The same problem surfaces on i586-pc-linux-gnu, except that GDB thinks
the variable is in %ss.  That illustrates a problem: there are two
register numbering schemes that are in wide use: the "default"
register map (dbx_register_map), and the Dwarf register map
(svr4_dbx_register_map).

In GDB we have STAB_REG_TO_REGNUM, DWARF_REG_TO_REGNUM, etc.  We have
to provide a suitable definition for those in tm-i386.h.  However, the
problem mentioned above makes it a bit tricky, since GCC always uses
the same register numbering scheme, regardless of the actual debugging
format.  Most ELF targets use the Dwarf scheme, even if the debugging
format is stabs.  And it seems that DJGPP uses the "default" scheme,
even if you ask for Dwarf 2 debugging info.

I'm working on a patch, and I'll try to provide some reasonable
defaults.  But most targets will have to override some of these
defaults.

Mark

Re: i386 register numbering

[Eli Zaretskii]

> From: Mark Kettenis <kettenis@science.uva.nl>
> Date: 28 Jul 2001 13:54:19 +0200
> 
> In GDB we have STAB_REG_TO_REGNUM, DWARF_REG_TO_REGNUM, etc.

Ah, I missed that additional layer of translation.  Thanks for
pointing it out.

> We have
> to provide a suitable definition for those in tm-i386.h.  However, the
> problem mentioned above makes it a bit tricky, since GCC always uses
> the same register numbering scheme, regardless of the actual debugging
> format.  Most ELF targets use the Dwarf scheme, even if the debugging
> format is stabs.  And it seems that DJGPP uses the "default" scheme,
> even if you ask for Dwarf 2 debugging info.

DJGPP supports 3 debug info formats: COFF, stabs, and (lately) DWARF2;
the default is COFF.  (Btw, I don't see any COFF_REG_TO_REGNUM.)  I'm
guessing that no one (including myself ;-) bothered to review the
register naming scheme when support for stabs and DWARF2 was added...

But there's something in your explanation that I don't get: if GCC
always uses the same scheme, no matter what the debug info, and since
all i386 targets use the same i386.h header which defines this scheme,
how come DJGPP can use something different than the other targets?
What am I missing?

> I'm working on a patch, and I'll try to provide some reasonable
> defaults.  But most targets will have to override some of these
> defaults.

Thanks.

Re: i386 register numbering

[Andrew Cagney]

>> From: Mark Kettenis <kettenis@science.uva.nl>
>> Date: 28 Jul 2001 13:54:19 +0200
>> 
>> In GDB we have STAB_REG_TO_REGNUM, DWARF_REG_TO_REGNUM, etc.


Yep.

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.


>> We have
>> to provide a suitable definition for those in tm-i386.h.  However, the
>> problem mentioned above makes it a bit tricky, since GCC always uses
>> the same register numbering scheme, regardless of the actual debugging
>> format.  Most ELF targets use the Dwarf scheme, even if the debugging
>> format is stabs.  And it seems that DJGPP uses the "default" scheme,
>> even if you ask for Dwarf 2 debugging info.
> 
> 
> DJGPP supports 3 debug info formats: COFF, stabs, and (lately) DWARF2;
> the default is COFF.  (Btw, I don't see any COFF_REG_TO_REGNUM.)  I'm
> guessing that no one (including myself  [;-)] bothered to review the
> register naming scheme when support for stabs and DWARF2 was added...
> 
> But there's something in your explanation that I don't get: if GCC
> always uses the same scheme, no matter what the debug info, and since
> all i386 targets use the same i386.h header which defines this scheme,
> how come DJGPP can use something different than the other targets?
> What am I missing?


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!

	Andrew

Re: i386 register numbering

[Mark Kettenis]

   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

Re: i386 register numbering

[Mark Kettenis]

   Date: Sat, 28 Jul 2001 08:14:26 -0400
   From: Eli Zaretskii <eliz@delorie.com>

   DJGPP supports 3 debug info formats: COFF, stabs, and (lately) DWARF2;
   the default is COFF.  (Btw, I don't see any COFF_REG_TO_REGNUM.)  I'm
   guessing that no one (including myself ;-) bothered to review the
   register naming scheme when support for stabs and DWARF2 was added...

With the patch that I just checked in, COFF and stabs should do the
right thing for DJGPP.  DWARF2 will probably still give you the wrong
register.  You might want to consider changing GCC such that it uses
the standard Dwarf renumbering for DWARF2.  I don't think it really
matters since there aren't any native tools that you need to be
compatible with.  On the other hand, using DWARF2 with a numbering
scheme that nobody else uses, might trigger some bugs.
If you don't change GCC you should probably override
DWARF2_REG_TO_REGNO in config/i386/tm-go32.h.

   But there's something in your explanation that I don't get: if GCC
   always uses the same scheme, no matter what the debug info, and since
   all i386 targets use the same i386.h header which defines this scheme,
   how come DJGPP can use something different than the other targets?
   What am I missing?

Several GCC targets redefine DBX_REGISTER_NUMBER, see for example
linux.h in that same directory.

Mark

Re: i386 register numbering

[Andrew Cagney]

> 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  [:-(] .


Regarding MMX, yes.

For the basic FP register, see my recent RFC post about adding 
builtin_type_floatformat*:

http://sources.redhat.com/ml/gdb-patches/2001-07/msg00624.html


You're saying is that a i386 register is always formatted as 
floatformat_i387_ext. Correct?  Consequently, with the above change (and 
related FIXMEs) in place, all the CONVERT* code could be deleted and 
instead REGISTER_VIRTUAL_TYPE would just return 
builtin_type_floatformat_i387_ext and GDB would internaly handle all the 
conversion problems.

	Andrew

Re: i386 register numbering

[Mark Kettenis]

   Date: Sat, 28 Jul 2001 14:06:43 -0400
   From: Andrew Cagney <ac131313@cygnus.com>

   For the basic FP register, see my recent RFC post about adding 
   builtin_type_floatformat*:

   http://sources.redhat.com/ml/gdb-patches/2001-07/msg00624.html

A few comments then :-):

 * I'm not sure whether "The assertion (TYPE_LENGTH(T) *
   TARGET_CHAR_BIT == TYPE_FLOATFORMAT(T)->totalsize)" should really
   hold.  On the i386 the ISA has a 80-bit extended floating-point,
   while the ABI builds a 80-bit, 96-bit or even 128-bit
   floating-point type on top of it.  Giving the latter three each
   their own floatformat would make it hard to use the floatformat to
   check whether they are equivalent or not.

 * As a consequence TARGET_FLOAT_BIT, TARGET_DOUBLE_BIT, etc. isn't
   really redundant.

 * extract_floating and store_floating should indeed be using
   floatformat instead of lengths to match types.

 * Deprecating REGISTER_CONVERT_TO_VIRTUAL isn't possible without
   significant changes to findvar.c:value_from_register().  See below.

As is, the patch will break the i386 target because of the assertion.
See above.  Apart from these assertions, the patch looks fine though.

   You're saying is that a i386 register is always formatted as 
   floatformat_i387_ext. Correct?

If we don't consider MMX, yes indeed!  You can use the FPU for integer
or BCD arithmetic, but even then the register is formatted as
floatformat_i387_ext.

Note that a long double is stored in memory in the same format, with
two extra bytes of padding.  There is no real conversion done between
the two.  The two extra bytes of padding are not really part of the
ISA.  The instructions to load from and store floating-point values
into memory operate on 80-bit memory blocks.

   Consequently, with the above change (and related FIXMEs) in place,
   all the CONVERT* code could be deleted and instead
   REGISTER_VIRTUAL_TYPE would just return
   builtin_type_floatformat_i387_ext and GDB would internaly handle
   all the conversion problems.

It seems to me that currently, GDB cannot handle those conversion
problems without REGISTER_CONVERT_TO_VIRTUAL, and that your FIXMEs
don't address this.  I discovered today that if the debug info says
that a variable is a `double' or a `float' and that it lives in a
register instead of memory, it is REGISTER_CONVERT_VIRTUAL that has to
do the conversion.  If REGISTER_CONVERT_TO_VIRTUAL isn't available,
findvar.c:value_from_register() will fail miserably.

Mark

Re: i386 register numbering

[Andrew Cagney]

>  * extract_floating and store_floating should indeed be using
>    floatformat instead of lengths to match types.


Do you mean to convert to/from DOUBLEST from/to a target floating point 
representation as specified by floatformat.


>  * Deprecating REGISTER_CONVERT_TO_VIRTUAL isn't possible without
>    significant changes to findvar.c:value_from_register().  See below.


Yes, it requires change.


> As is, the patch will break the i386 target because of the assertion.
> See above.  Apart from these assertions, the patch looks fine though.


The FIXME mentioned that :-)


>    You're saying is that a i386 register is always formatted as 
>    floatformat_i387_ext. Correct?
> 
> If we don't consider MMX, yes indeed!  You can use the FPU for integer
> or BCD arithmetic, but even then the register is formatted as
> floatformat_i387_ext.
> 
> Note that a long double is stored in memory in the same format, with
> two extra bytes of padding.  There is no real conversion done between
> the two.  The two extra bytes of padding are not really part of the
> ISA.  The instructions to load from and store floating-point values
> into memory operate on 80-bit memory blocks.


The change in part works because it treats i387_ext80, i387_ext96 and 
i387_ext128 as different types.  Think of it as a ``purest'' position. 
If code has i387_ext80 but needs i387_ext128 then the conversion sequence:

	DOUBLEST tmp;
	extract_floatformat (&in, &tmp, floatformat_i387_ext80);
	store_floatformat (&tmp, &out, floatformat_i387_ext128);

would be needed.   It may be possible, on some architectures, to tune 
those functions so that the above are implemented using memmov().


>    Consequently, with the above change (and related FIXMEs) in place,
>    all the CONVERT* code could be deleted and instead
>    REGISTER_VIRTUAL_TYPE would just return
>    builtin_type_floatformat_i387_ext and GDB would internaly handle
>    all the conversion problems.
> 
> It seems to me that currently, GDB cannot handle those conversion
> problems without REGISTER_CONVERT_TO_VIRTUAL, and that your FIXMEs
> don't address this.  I discovered today that if the debug info says
> that a variable is a `double' or a `float' and that it lives in a
> register instead of memory, it is REGISTER_CONVERT_VIRTUAL that has to
> do the conversion.  If REGISTER_CONVERT_TO_VIRTUAL isn't available,
> findvar.c:value_from_register() will fail miserably.


value_from_register() will need work.  so will (ulgh) get_saved_register().

For value_from_register(), assuming get_saved_register() provides not 
only the raw bytes but also their type, does the sequence:

	get_saved_register (...., regval, regtype);
	if (register_convertible (regnum))
	  convert from regval/regtype to value_ptr/type
	  using standard GDB value conversion code

appear sufficient.  There are definitly going to be warts.  Check the 
MIPS REGISTER_CONVERT_TO_TYPE.

	Andrew