Re: 8-byte register values on a 32-bit machine

[Mark Kettenis <kettenis@chello.nl>]

   Date: Sat, 1 Mar 2003 11:09:29 -0800
   From: Joel Brobecker <brobecker@gnat.com>

   > Yup, that's defenitely what it does for stabs, and from looking at the
   > code, it does it for other debug formats as well (including dwarf-2).
   > Right now, GDB interprets this as that the variable is stored in
   > consecutive registers starting at the register number indicated by the
   > debug info.  I have a strong suspicion that there are several GDB
   > targets that rely on this behaviour.  However, it isn't working for
   > the i386 since GCC allocates the registers in an order that's
   > different from the order that GDB uses.

   What I have seen as well is GCC an 8 bytes structure over 2 registers
   (2 fields of 4 bytes, one field on each register). The first register
   used (and specified in the stabs info) was %ebx, and the next one was
   sort of consecutive. It was %esi. The only thing is that there are two
   special registers in the middle (%esp, and %ebp) :-).

Yup, GCC allocates %esi after %ebx.  By the way, the fact that GDB
"thinks" that %esp follows %ebx makes things very interesting if you
happen to modify the last 4 bytes of said structure.  This will make
GDB modify the stack pointer, which most likely makes your program
blow up.

   Because of this, even if we modified GCC to allocate the registers in
   the same order as the GDB order (or modify the GDB order, if that's
   possible), we'll still have situations where this is not going to work.

Modifying GCC probably wouldn't be a good idea.  The order on which
GCC allocates the registers seems to be chosen such that it generates
optimized code.  Modifying the GDB order isn't possible (yet) because
of the remote protocol.

   I think we've lost the stabs battle.

Actually, the order in which GCC allocates its registers has been the
same for many years (at least since GCC 2.6.3 which was released in
1994).  We only need to teach GDB this order in order to make GCC do
the right thing for code generated by any version of GCC that's still
in wide use.  I posted a preliminary patch that does this early
februari.  If we're concerned about aother compilers than GCC, we can
probably tweak things that we only use the heuristics in my patch when
the code was compiled by GCC.

   So I started to look into the DWARF2 format, but could not find
   anything that helps. Does anybody know if this format supports this
   sort of situation?

The idea was that DWARF2 location expressions could help.  I believe
GCC should emit location descriptors that are concatenation of
locations, just like it already does for complex variables.

Mark