Re: IA32: printing FP register variables

[Michael Meissner <meissner@cygnus.com>]

On Thu, Jul 08, 1999 at 10:59:00PM -0600, Jeffrey A Law wrote:
> 
>   In message < 000d01bec9c2$06f4fdb0$3404010a@metrowerks.com >you write:
>   > I would suggest that we may use a "negative" ST value.  The debugger can
>   > always know the depth of the stack from reading the status registers, so
>   > saying that something was in ST(7) could be interpreted as the top-most
>   > stack item, ST(6) as one below that, and so on.  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.
> Unfortunately, I believe the relative positions of items does change.
> 
> Jim's brought up an interesting problem.
> 
> I believe dwarf2 can handle this in a straightforward manner -- it has the
> capability to say variable X is in location Y between points A & B and in
> location Z between points C & D.
> 
> This is more difficult to do with stabs, but possible since Cygnus defined a
> set of extensions to describe the same basic concepts.
> 
> The more difficult problem is getting information about the state of the
> FP regstack  into dwarf2out.c & dbxout.c in a reasonably clean manner.

This is actually a symptom of a much deeper problem that I would like to see
addressed in the compiler at some point, namely tracking variables being
reloaded, etc.  For example, if the compiler determines that a variable is on
the stack, but needs to load up a variable into a register to work on it
(reload in gcc speak), we currently don't track this, so if you put a
breakpoint after the load has been done, but before it is used, you won't be
able to change the value to affect the running of the program.

Also when I first did the LRS changes, I thought that you could do LRS debug
information in any debug format, including crippled ones like COFF, if you were
willing to create a new block for every state change (ie, variable moving from
stack to register).

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482
From amylaar@cygnus.co.uk Fri Jul 09 10:31:00 1999
From: Joern Rennecke <amylaar@cygnus.co.uk>
To: bcombee@metrowerks.com (Ben Combee)
Cc: jimb@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 10:31:00 -0000
Message-id: <199907091724.SAA31114@phal.cygnus.co.uk>
References: <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com>
X-SW-Source: 1999-q3/msg00023.html
Content-length: 520

> I would suggest that we may use a "negative" ST value.  The debugger can
> always know the depth of the stack from reading the status registers, so
> saying that something was in ST(7) could be interpreted as the top-most
> stack item, ST(6) as one below that, and so on.  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.

I think you get more stable position designations by considering the
position relative to the bottom of the stack.
From bcombee@metrowerks.com Fri Jul 09 10:34:00 1999
From: "Ben Combee" <bcombee@metrowerks.com>
To: <egcs@egcs.cygnus.com>, <gdb@sourceware.cygnus.com>
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 10:34:00 -0000
Message-id: <00d401beca31$3d752c10$3404010a@metrowerks.com>
References: <199907091724.SAA31114@phal.cygnus.co.uk>
X-SW-Source: 1999-q3/msg00024.html
Content-length: 1729

> > I would suggest that we may use a "negative" ST value.  The debugger can
> > always know the depth of the stack from reading the status registers, so
> > saying that something was in ST(7) could be interpreted as the top-most
> > stack item, ST(6) as one below that, and so on.  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.
>
> I think you get more stable position designations by considering the
> position relative to the bottom of the stack.

Yes, that's what I meant -- not what I really said, however.  When I was
writing that, I was thinking of memory stack growing downwards in memory,
hence my top/bottom mixmatch.  The temps are almost always at the top, with
allocated variables there at the bottom.

With the CW compiler, we generally use a similar idea to how the new EGCS
stuff works -- actually, we tend to first figure out the register pressure
from temps needed during expression evaluation, then allocate the some of
the variables to the stack locations available at any particular time.  So,
an item at the bottom of the stack will stay there.

I can see Jim's point -- if you use FXCHG to move items around on the stack,
something you need to do for efficient Pentium codegen, then a variable
won't have a stable location referenced from either the top or the bottom.
On newer chips like the Pentium II and K6, we've seen very little gain from
using FXCHG due to the automatic register renaming going on behind the
scenes.

I like the idea of DWARF2's more complex variable mapping ability that was
mentioned -- but, we need a binding to the complete set of IA32 registers:
integer, special purpose, FP/MMX, and SSE.