Re: IA32: printing FP register variables

[Jim Blandy <jimb@cygnus.com>]

> I have a similar problem as you have, Jim.  I'm working on the CodeWarrior
> x86/Linux port, and I have no way to represent that a value has been
> allocated to a MMX register.  While CW will also allocate local variables to
> floating point stack locations, we don't emit any useful debugging info for
> those variables.

I don't have an MMX manual handy, but it seems like a much easier case
than the FPU, since the registers don't shift around every time you do
an operation.

> As long as the relative position of items on the stack didn't change
> (this var is always 2 from the top), this should be OK.

Well, the reason this problem seems hard to me is exactly because the
position of items relative to the top of the stack *will* change,
whenever you execute instructions like FILD, FDIVP, etc.  If they were
a constant distance, then we could simply assign register numbers to
ST(0) -- ST(7) in the usual way, and everything would work.
From jimb@cygnus.com Fri Jul 09 11:14:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: law@cygnus.com
Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 11:14:00 -0000
Message-id: <np1zehu1vd.fsf@zwingli.cygnus.com>
References: <4264.931496789@upchuck.cygnus.com>
X-SW-Source: 1999-q3/msg00027.html
Content-length: 1208

STABS's live range splitting notation can certainly do the job
correctly, but I wonder whether it can do it efficiently.  For every
instruction that changes TOP, you have to start a new range for every
variable.  So the size of debug info is O(number of insns * average
number of live variables).

Without knowing too much about how the FPU register allocation works,
I'd guess that GCC could simply emit a stab after each instruction
which changes the depth, whose value is the code address and whose
`desc' is the distance from TOP to the base used for register
numbering.

That is, if we've got an N_RSYM saying that foo lives in ST(2), and
we've just seen an N_FPSTACK stab with a value of 3, then we'll look
for foo in ST(5).  Or change the sign of things as appropriate.

This means the size of the debug info is O(number of insns).  On the
other hand, it's more work to implement in GDB.

In either case, GCC needs to be fixed to propagate the register
numbers through the stackifier.  At that point, if it is
straightforward to get GCC to emit LRS info, we could give that a try
(no work for me, assuming GDB's LRS code works!).  If that's too big,
then maybe we could try implementing a depth stab.
From amylaar@cygnus.co.uk Fri Jul 09 11:22:00 1999
From: Joern Rennecke <amylaar@cygnus.co.uk>
To: jimb@cygnus.com (Jim Blandy)
Cc: law@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 11:22:00 -0000
Message-id: <199907091822.TAA31184@phal.cygnus.co.uk>
References: <np1zehu1vd.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00028.html
Content-length: 494

> STABS's live range splitting notation can certainly do the job
> correctly, but I wonder whether it can do it efficiently.  For every
> instruction that changes TOP, you have to start a new range for every
> variable.  So the size of debug info is O(number of insns * average
> number of live variables).

You only have to care about variables that are live in the register stack
before or after the operation.  So you can use an upper bound of 8.
Hence the deubg info is O(number of insns).
From bcombee@metrowerks.com Fri Jul 09 12:33:00 1999
From: "Ben Combee" <bcombee@metrowerks.com>
To: "Jim Blandy" <jimb@cygnus.com>
Cc: <egcs@egcs.cygnus.com>, <gdb@sourceware.cygnus.com>
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 12:33:00 -0000
Message-id: <014f01beca41$c42b4e50$3404010a@metrowerks.com>
References: <199907090356.WAA01337@zwingli.cygnus.com> <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> <np3dyxu2ua.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00029.html
Content-length: 1281

> > As long as the relative position of items on the stack didn't change
> > (this var is always 2 from the top), this should be OK.
>
> Well, the reason this problem seems hard to me is exactly because the
> position of items relative to the top of the stack *will* change,
> whenever you execute instructions like FILD, FDIVP, etc.  If they were
> a constant distance, then we could simply assign register numbers to
> ST(0) -- ST(7) in the usual way, and everything would work.

I guess an example would help...

Consider this code where we have doubles a and b allocated to two spots on
the FP stack (excuse the MASM notation... I'm not yet fluent in gas syntax)

fld a_value        ;; a is at bottom_offset(0)
fld b_value        ;; b is at bottom_offset(1)
fld1               ;; temp with no debug info
fadd st2           ;; result of (a + 1)
fstp st1           ;; stored into b, pop the temp

At each instruction, the invariant that a is 0 from the bottom and b is 1
from the bottom holds.  Note, the bottom of the stack can be known by the
debugger via scanning the FPU tag word from the TOP element looking for a FP
register that is empty.  All this info is provided by an FSAVE or FSTENV.

--
Ben Combee, x86/Win32/Novell/Linux CompilerWarrior
http://www.metrowerks.com/