Re: IA32: printing FP register variables

Re: IA32: printing FP register variables

[Michael Meissner]

| I'm sorry, Ben, but I'm still confused about how you find the FP
| register containing a variable.  I think there's a fundamental,
| difficult problem here which you don't seem to be mentioning at all.
| Perhaps you have solved it already, and assume we have too.
| 
| In code generated by your compiler, is the value of TOP (the three-bit
| FPU stack pointer) at function entry known at compile time?  Or does
| its value depend on the caller, and the caller's caller, etc.?

Yes, IIRC the IA32 abi explicitly requires the FP stack to be empty at the time
of a call.  Otherwise, you couldn't write any code using it all, since the
stack might be full and any value pushed would result in an exception.

Re: IA32: printing FP register variables

[Michael Meissner]

| I'm sorry, Ben, but I'm still confused about how you find the FP
| register containing a variable.  I think there's a fundamental,
| difficult problem here which you don't seem to be mentioning at all.
| Perhaps you have solved it already, and assume we have too.
| 
| In code generated by your compiler, is the value of TOP (the three-bit
| FPU stack pointer) at function entry known at compile time?  Or does
| its value depend on the caller, and the caller's caller, etc.?

Yes, IIRC the IA32 abi explicitly requires the FP stack to be empty at the time
of a call.  Otherwise, you couldn't write any code using it all, since the
stack might be full and any value pushed would result in an exception.

Re: IA32: printing FP register variables

[Jim Blandy]

The disadvantages of base-relative numbering are:
- It's unexpected.  Every existing system saves registers in
  top-relative order.  The IA32's FSAVE instruction saves them
  top-relative.  Assembly code refers to them top-relative.
- I'm not sure how to implement something like "print $st0".
- It requires straightforward but non-trivial support in GDB's
  target-specific code to find the FP stack base and load the register
  array properly.

In that light, it had better save us a significant amount of space
over top-relative numbering if we're going to go to the trouble.  But
we have no idea how much space it will save.

Once the other internal work is done, would the EGCS folks be willing
to experiment with both, and give us some sense of how much difference
it makes?

If the savings are negligible, I'm not sure it's worth the hair.

Re: IA32: printing FP register variables

[Jim Blandy]

I hope that I'm not mixing up my priorities by worrying about debug
size.  But since a register numbering is a matter of public protocol,
it will be more trouble to change it later than to make a good choice
now.

There are only three possible numberings that make any sense:
physical, top-relative, or base-relative.

Physical is not possible, since the compiler doesn't know the value of
TOP at function entry.

top-relative is, I think we all agree, the least stable of all
possible orderings.

So base-relative is what we have left.  We will still require LRS info
in almost every case, but it's better than the alternatives.

If GCC will have trouble generating base-relative register numbers
(if, for example, regstack has no concept of the FP stack base), then
that would tip the scales.  If someone can find an i386 STABS system
that uses another numbering, that would too.

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < 19990712191723.E3871@rjlhome.sco.com >you write:
  > >   > Hmm.  What other IA32 compilers produce STABS?  How do they number FP
  > >   > registers?
  > > Dunno.  Robert -- can you see what the SCO compilers do with this stuff?
  > > That might be interesting.
  > 
  > I know of zero SCO-supplied compilers that produce stabs.  There are
  > tools that do COFF (a.k.a. SDB) and tools that do ELF (dwarf-1 and
  > dwarf-2).  Is the really stab-specific, or do you want to know in
  > general how they're numbered in whatever format is used?
The general case would be good to know as a starting point.  Particularly
what gets inencoded into the register # field in the dwarf records.

  > Since I speak no debugging formats and I speak zero floating point I'll
  > have to dig for an answer.   If, OTOH, there's some program I can build 
  > that'll help answer the question, shoot it my way.
Not really.  I suspect you could probably take just about anything with a few
FP ops from the gcc testsuite as a sample program.

jeff

Re: IA32: printing FP register variables

[Joern Rennecke]

> 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).

Re: IA32: printing FP register variables

[David Edelsohn]

>>>>> Philipp Thomas writes:

Philipp> Sorry for jumping in, but does anybody know *why* intel did that
Philipp> braindamage, i.e. designed the original 8087 using a stack instead of
Philipp> memory mapped registers? I remember once playing with a Weitek (costly
Philipp> little beasts :), which did offer memory mapped access and that was
Philipp> noticeably faster than the stack.

	Advice from IBM -- precursor to register window research.

David

Re: IA32: printing FP register variables

[Richard Henderson]

On Mon, Jul 19, 1999 at 03:26:18PM -0500, Jim Blandy wrote:
> Once the other internal work is done, would the EGCS folks be willing
> to experiment with both, and give us some sense of how much difference
> it makes?

Yes.  It seems a reasonable thing to try.


r~

Re: IA32: printing FP register variables

[Richard Henderson]

On Tue, Jul 13, 1999 at 03:25:02PM -0500, Jim Blandy wrote:
> But numbering registers relative to the FP stack base will still reduce
> the number of ranges substantially, won't it?

Yes.


r~

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < np908psfqu.fsf@zwingli.cygnus.com >you write:
  > Okay, but do you really want to emit up to eight stabs at every FP
  > instruction that changes the stack?
If that's what it takes to get access to FP variables, yes.

Another option would be to set up a stack in the debug symbols and
push/pop the debug symbol stack in a manner similar to what we do with
the actual FP regstack.  There's some serious issues with how we do this
portably, but it's worth thinking about.

  > I dunno --- maybe it's not a big deal.  It may not be worth creating a
  > whole new form of debugging info to save that space.  It is certainly
  > a problem the various LRS representations handle.  I'd certainly agree
  > we should try it first.
Compactness of debug symbols hasn't ever been a serious concern.  At some
point it will need to be addressed though.

However, we need to keep in mind this is only an issue for the x86.  No other
port has this kind of braindamage.

jeff

Re: IA32: printing FP register variables

[Joern Rennecke]

> I'm not sure this is safe either.  Consider what happens at basic block
> boundaries to the regstack.   I believe variables location relative to 
> the bottom of the stack can change at a basic block boundary.

Huh?  Why that?  The FPU doesn't know about the control flow.

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < np3dyxu2ua.fsf@zwingli.cygnus.com >you write:
  > 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.
Correct.  While the MMX registers are overloaded on the FPU registers, 
they do not stack like FP operations do.

  > 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.
Precisely.

jeff

Re: IA32: printing FP register variables

[Jim Blandy]

Would it be possible to re-derive some of the LRS info by analyzing
the final code?  The less information you need to carry through the
optimizations, the better, it seems to me.

Re: IA32: printing FP register variables

[Jim Blandy]

> 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).

I wonder if it's a good idea to abuse blocks this way.  If the user
has a function like this:

    foo ()
    {
      {
	int a;
	...
      }
      {
	int a;
	...
      }
    }

and, while control is in the first inner block, asks the debugger to
monitor the value of 'a' as he steps, it would be nice if the debugger
could tell that the 'a' in the second block is actually a different
variable, and is not the one the user asked about.

If you use blocks the way you suggest, I'm not sure how GDB could tell
the difference between two separate variables with the same name, and
a single variable which exists in two blocks created to capture
different life ranges.

The STABS LRS stuff, while quirky, doesn't have this problem.

Re: IA32: printing FP register variables

[Richard Henderson]

On Mon, Jul 12, 1999 at 06:09:50PM -0500, Jim Blandy wrote:
> If GDB can find the base of the FP stack reliably, using the method
> that Ben Combee suggests, then we don't need LRS at all to describe
> variables' homes.  If we simply number the FP registers relative to
> the base of the FP stack, their names won't change as insns push and
> pop FP values.

You can find the base of the stack, it's true.  But that does you
no good whatsoever. 

Consider the following sequence:

	(set (reg f0) (add (reg f0) (reg f1)))
	(set (reg f2) (add (reg f2) (reg f3)))

Assuming no register deaths, so there's no popping to add to the
confusion, this will ultimately get transformed to

	fadd	%st(1)
	fxch	%st(2)
	fadd	%st(3)

Since there's no popping, the base of the FP stack has not changed.
However, f2 and f0 were swapped, so that f2 would be at the top of
the stack, so that we can perform the second operation.

That's not to say that you can't use the FP base to eliminate the
need to encode the pushes and pops into the debug information, but
you can't get away from bazillions of live ranges.


r~

Re: IA32: printing FP register variables

[Jim Blandy]

> Then the scan code sees that there are no empty registers, so the eighth
> register is the bottom of the stack.  The IA32 FPU itself uses this logic --
> if you push something on the stack such that TOP gets incremented to point
> to a non-empty value, you get a stack overflow.

Right --- of course.  That would work.  So we could use bottom-relative
register numbers.

Re: IA32: printing FP register variables

[Jeffrey A Law]

  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.

jeff
dbxout.c 
clean manner 
same mechanisms 


  > 
  > --
  > Ben Combee, x86/Win32/Novell/Linux CompilerWarrior
  > http://www.metrowerks.com/
  > ----- Original Message -----
  > From: Jim Blandy <jimb@cygnus.com>
  > To: <egcs@egcs.cygnus.com>; <gdb@sourceware.cygnus.com>
  > Sent: Thursday, July 08, 1999 10:56 PM
  > Subject: IA32: printing FP register variables
  > 
  > 
  > >
  > > This is a question about how GDB should grok code produced by GCC, so
  > > I'm posting it to both lists.
  > >
  > > On IA32 processors, how should GDB find the values of variables which
  > > live in floating-point registers?  At the moment, it can't do this
  > > reliably, which must be a royal pain for people doing numeric work.
  > >
  > > It's a non-trivial problem.  GCC simply places the variables on the
  > > top of the FP stack, so which physical FP registers receive them
  > > depends on the value of the floating-point stack pointer upon entry to
  > > the function.  And since GCC uses the floating-point stack to hold
  > > temporary values, a variable's offset from the stack pointer changes
  > > as the function executes.
  > >
  > > This makes it difficult for GDB to find a variable's value as the
  > > function executes.  In order to find a variable, it needs to know how
  > > many intermediate results are presently above it on the stack.  GCC
  > > knows this, but doesn't give GDB any hints about it in the debugging
  > > info.
  > >
  > > What does the register number which GCC emits now mean?  If an N_RSYM
  > > stab has a value of 8, what does that mean?  ST(0)?  When?  Every
  > > variable is ST(0) when it's just been pushed.
  > >
  > > Should GCC emit more debug info, to help GDB find variables?
  > >
  > > Should GDB derive this info on its own?  It could disassemble the
  > > function, starting from the end of the prologue, and count pushes and
  > > pops, building a table mapping PC values onto stack depths.  (This
  > > assumes that the stack depth is constant at a given PC.)  That would
  > > require no debug info, but would be a pain to implement.
  > >
  > 
  > 

Re: IA32: printing FP register variables

[Joern Rennecke]

> Okay, but do you really want to emit up to eight stabs at every FP
> instruction that changes the stack?

Well, if the bottom of stack - relative information is workable, I'd prefer
that.
I suppose you can detect the eight-registers-used situation by noting that
there is no empty register.

Re: IA32: printing FP register variables

[Ben Combee]

> > 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.
>
> That could work, but what if you happen to have all eight registers in
> use?

Then the scan code sees that there are no empty registers, so the eighth
register is the bottom of the stack.  The IA32 FPU itself uses this logic --
if you push something on the stack such that TOP gets incremented to point
to a non-empty value, you get a stack overflow.

Of course, all this is also based on the assumption, explicit in the Win32
ABI, that the FPU stack is empty on entry to a function.  I think this holds
for the x86 Linux ABI as well -- I can't see any logical other way to do it
since you don't generally know how many levels of nesting there are when
your function is called.

Re: IA32: printing FP register variables

[Richard Henderson]

On Mon, Jul 26, 1999 at 01:42:41PM -0500, Jim Blandy wrote:
> Okay.  So the current plan is:
> 
> 1) EGCS folks get regstack to actually propagate the variable/register
>    mapping to its output accurately.

Yes, this is a reasonable plan.  As to a time frame... I don't know.

What we need is a good infrastructure for handling LRS debug info in
a convenient form within the compiler.  Whether this gets emitted as
dwarf2 location ranges, or stabs live ranges, or as a set of virtual
lexical blocks.  What Cygnus has now for LRS just won't work when the
size live ranges are on the order of instructions.

If someone has brilliant ideas how to manage and manipulate this stuff
in a way that won't make things an absolute nightmare, I'd be glad to
hear it.

I'll throw out one idea -- live ranges must always begin with a store.
What if we put a REG_START_RANGE in places that a user variable moves
to a new location.  And a REG_END_RANGE note in places a user variable
truely dies and its register gets re-allocated to some temp.  The value
of the note would be some canonical token that lets us match up with
the DECL in question.

Just before, or in the process of, emitting debug info, we use the
CFG and the REG_*_RANGE notes to transform this somewhat fluid form
into something that the debugger can use.

A particularly major open issue is how the optimizers can easily know
when they need to create these notes, and which variables the notes 
are being created for.  I could easily see it being a not insignificant
task to find this, given that it's all scattered about.  But the fact
that it's scattered about is crucial to being resiliant against
ever-changing insn sequences.

The extra memory and time might even call for it only being enabled
at -g3 or something.  Something we'll have to examine.

Thoughts?



r~

IA32: printing FP register variables

[Jim Blandy]

This is a question about how GDB should grok code produced by GCC, so
I'm posting it to both lists.

On IA32 processors, how should GDB find the values of variables which
live in floating-point registers?  At the moment, it can't do this
reliably, which must be a royal pain for people doing numeric work.

It's a non-trivial problem.  GCC simply places the variables on the
top of the FP stack, so which physical FP registers receive them
depends on the value of the floating-point stack pointer upon entry to
the function.  And since GCC uses the floating-point stack to hold
temporary values, a variable's offset from the stack pointer changes
as the function executes.

This makes it difficult for GDB to find a variable's value as the
function executes.  In order to find a variable, it needs to know how
many intermediate results are presently above it on the stack.  GCC
knows this, but doesn't give GDB any hints about it in the debugging
info.

What does the register number which GCC emits now mean?  If an N_RSYM
stab has a value of 8, what does that mean?  ST(0)?  When?  Every
variable is ST(0) when it's just been pushed.

Should GCC emit more debug info, to help GDB find variables?

Should GDB derive this info on its own?  It could disassemble the
function, starting from the end of the prologue, and count pushes and
pops, building a table mapping PC values onto stack depths.  (This
assumes that the stack depth is constant at a given PC.)  That would
require no debug info, but would be a pain to implement.

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < 199907122349.AAA25740@phal.cygnus.co.uk >you write:
  > > I'm not sure this is safe either.  Consider what happens at basic block
  > > boundaries to the regstack.   I believe variables location relative to 
  > > the bottom of the stack can change at a basic block boundary.
  > 
  > Huh?  Why that?  The FPU doesn't know about the control flow.
Consider two threads of control, each with one variable on the FP stack.

At some point they merge.  One variable has to be on the bottom, the other
on the top.

regstack has to track this stuff and emit appropriate code at block boundaries
to move stuff around via copies.

It is also why I believe an LCM based copy propagation algorithm can be used
to improve the code generated by regstack.


jeff

Re: IA32: printing FP register variables

[Ben Combee]

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 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.

--
Ben Combee, x86/Win32/Novell/Linux CompilerWarrior
http://www.metrowerks.com/
----- Original Message -----
From: Jim Blandy <jimb@cygnus.com>
To: <egcs@egcs.cygnus.com>; <gdb@sourceware.cygnus.com>
Sent: Thursday, July 08, 1999 10:56 PM
Subject: IA32: printing FP register variables


>
> This is a question about how GDB should grok code produced by GCC, so
> I'm posting it to both lists.
>
> On IA32 processors, how should GDB find the values of variables which
> live in floating-point registers?  At the moment, it can't do this
> reliably, which must be a royal pain for people doing numeric work.
>
> It's a non-trivial problem.  GCC simply places the variables on the
> top of the FP stack, so which physical FP registers receive them
> depends on the value of the floating-point stack pointer upon entry to
> the function.  And since GCC uses the floating-point stack to hold
> temporary values, a variable's offset from the stack pointer changes
> as the function executes.
>
> This makes it difficult for GDB to find a variable's value as the
> function executes.  In order to find a variable, it needs to know how
> many intermediate results are presently above it on the stack.  GCC
> knows this, but doesn't give GDB any hints about it in the debugging
> info.
>
> What does the register number which GCC emits now mean?  If an N_RSYM
> stab has a value of 8, what does that mean?  ST(0)?  When?  Every
> variable is ST(0) when it's just been pushed.
>
> Should GCC emit more debug info, to help GDB find variables?
>
> Should GDB derive this info on its own?  It could disassemble the
> function, starting from the end of the prologue, and count pushes and
> pops, building a table mapping PC values onto stack depths.  (This
> assumes that the stack depth is constant at a given PC.)  That would
> require no debug info, but would be a pain to implement.
>

Re: IA32: printing FP register variables

[Joern Rennecke]

> 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.

Re: IA32: printing FP register variables

[Jim Blandy]

> 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.

Re: IA32: printing FP register variables

[Philipp Thomas]

On Sat, 10 Jul 1999 17:09:56 -0600, Jeffrey A Law <law@cygnus.com>
wrote:

>However, we need to keep in mind this is only an issue for the x86.  No other
>port has this kind of braindamage.

Sorry for jumping in, but does anybody know *why* intel did that
braindamage, i.e. designed the original 8087 using a stack instead of
memory mapped registers? I remember once playing with a Weitek (costly
little beasts :), which did offer memory mapped access and that was
noticeably faster than the stack.

Only for the Ia64 it seems like they finally did it right. But as it
was a totally new architecture, they could probably throw away the
stack model more easily.

Philipp

-- 
You have moved your mouse. Windows must be rebooted for the
changes to take effect.

Re: IA32: printing FP register variables

[Michael Meissner]

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

Re: IA32: printing FP register variables

[Jim Blandy]

Hmm.  What other IA32 compilers produce STABS?  How do they number FP
registers?

If GDB can find the base of the FP stack reliably, using the method
that Ben Combee suggests, then we don't need LRS at all to describe
variables' homes.  If we simply number the FP registers relative to
the base of the FP stack, their names won't change as insns push and
pop FP values.

So the only work to be done is:
- GCC needs to propage the register/variable association through the
  stackifier, so it can produce coherent debug output.
- GDB needs to use Ben Combee's tactic for finding the base of the
  stack.

Re: IA32: printing FP register variables

[Ben Combee]

> > 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/

Re: IA32: printing FP register variables

[Joern Rennecke]

> Consider two threads of control, each with one variable on the FP stack.
> 
> At some point they merge.  One variable has to be on the bottom, the other
> on the top.
> 
> regstack has to track this stuff and emit appropriate code at block boundaries
> to move stuff around via copies.

Currently, flow will consider both variables live in the predecessor blocks
if they are live in the successor block.  We'd need better data & control
flow analysis to find cases where a varaible is indeed live only in a
subset of the predecessor blocks.

So I guess that you are talking about the case when the variables were
allocated in different positions in the register stack in the different
predecessor blocks.  That means that the number of live registers in the
FP stack doesn't change at the basic block boundary, but but the positions of
two or more variables change.  Since the stack usage stays the same,
the number of variables that change location is the same no matter if
we count from the top or from the bottom of the stack.
We'll have to emit enough debugging information as it takes then to
describe all these position changes.

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < npbtdlsg2i.fsf@zwingli.cygnus.com >you write:
  > In code generated by your compiler, is the value of TOP (the three-bit
  > FPU stack pointer) at function entry known at compile time?  Or does
  > its value depend on the caller, and the caller's caller, etc.?
Aren't all the FP registers on the x86 considered call-clobbered?  If
so, then there should be no FP regs live across a function call.

With that in mind, the state of the FP stack ought to be empty at the
start of each function.

Or am I missing something?  I'm not really an ia32 guru.

jeff

Re: IA32: printing FP register variables

[Jim Blandy]

> > See what 'z' looks like in the debug records.  It might be helpful to include
> > the entire assembly file since we'll also need to verify that 'z' ended up in
> > an FP reg.
> 
> I feel I'd be doing you a disservice in trying to interpret these
> since I know nothing about floating point and nothing about debugging
> records.  I'll report the results from any tests that you find useful,
> though.  I'm also not afraid to drag SCO's compiler dudes into private
> conversations for things like this but they've promised to kill me if I
> mention their names in the public lists. :-)  
> 
> I fed that snippet into the pertinent compilers that I had ready access
> to.  I've attached a tarball of the resulting .s files.  Here's the
> secret spy decoder ring.  The last one is dwarf-2 and should match
> what's shipped as the UDK and SVR5 (i.e. UnixWare 7) . The ELF ones are
> dwarf-1.
> 
>         icc -bcoff -S -g j.c ; mv j.s icc_coff.s
>         icc -belf -S -g j.c ; mv j.s icc_elf.s
>         /bin/cc -bcoff -S -g j.c ; mv j.s cc_coff.s
>         /bin/cc -belf -S -g j.c ; mv j.s cc_elf.s
>         /udk/usr/ccs/bin/cc -S -g j.c ; mv j.s svr5_elf.s
> 
> Stir in a few native GCC chains, the ancient Microsoft/XENIX tools, and
> some MIPS-cross stuff that I have laying around and you see that I live
> in an embarrassment of compiler poverty. :-)

That's a nice menagerie you've got there.

Unfortunately, these files don't contain enough information to tell
exactly how those compilers assign numbers to FP registers, or how the
debugger actually finds the value.

Could you ask your compiler/debugger guys how their compilers number
the IA32 FP registers?  If they assign a fixed register number to each
ST(i), could you ask them how the debugger finds the right ST(i) for a
given variable while the stack is being pushed and popped?  That is, a
variable which lives in ST(4) at one point will find itself in ST(6)
after two FLD instructions, and in ST(5) after an FADDP.  How would
the debugger find the variable at each point?  Or does the debugger
just lose when there are intermediate values on the FP stack?

Re: IA32: printing FP register variables

[Jim Blandy]

> > 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).

Okay, but do you really want to emit up to eight stabs at every FP
instruction that changes the stack?

I dunno --- maybe it's not a big deal.  It may not be worth creating a
whole new form of debugging info to save that space.  It is certainly
a problem the various LRS representations handle.  I'd certainly agree
we should try it first.

Re: IA32: printing FP register variables

[Jim Blandy]

I'm sorry, Ben, but I'm still confused about how you find the FP
register containing a variable.  I think there's a fundamental,
difficult problem here which you don't seem to be mentioning at all.
Perhaps you have solved it already, and assume we have too.

In code generated by your compiler, is the value of TOP (the three-bit
FPU stack pointer) at function entry known at compile time?  Or does
its value depend on the caller, and the caller's caller, etc.?

For a function like this:

    double
    dot_product (int n, double *a, double *b)
    {
      int i;
      double sum = 0;

      for (i = 0; i < n; i++)
	sum += a[i] * b[i];

      return sum;
    }

EGCS generates code like this:

    00000000 <dot_product>:
       0:	55             	pushl  %ebp
       1:	31 c0          	xorl   %eax,%eax
       3:	89 e5          	movl   %esp,%ebp
       5:	53             	pushl  %ebx
       6:	8b 5d 08       	movl   0x8(%ebp),%ebx
       9:	d9 ee          	fldz   
       b:	8b 4d 0c       	movl   0xc(%ebp),%ecx
       e:	8b 55 10       	movl   0x10(%ebp),%edx
      11:	39 d8          	cmpl   %ebx,%eax
      13:	7d 18          	jnl    2d <dot_product+0x2d>
      15:	8d 74 26 00    	leal   0x0(%esi,1),%esi
      19:	8d bc 27 00 00 	leal   0x0(%edi,1),%edi
      1e:	00 00 
      20:	dd 04 c1       	fldl   (%ecx,%eax,8)
      23:	dc 0c c2       	fmull  (%edx,%eax,8)
      26:	40             	incl   %eax
      27:	39 d8          	cmpl   %ebx,%eax
      29:	de c1          	faddp  %st,%st(1)
      2b:	7c f3          	jl     20 <dot_product+0x20>
      2d:	5b             	popl   %ebx
      2e:	89 ec          	movl   %ebp,%esp
      30:	5d             	popl   %ebp
      31:	c3             	ret    
      32:	8d b4 26 00 00 	leal   0x0(%esi,1),%esi
      37:	00 00 
      39:	8d bc 27 00 00 	leal   0x0(%edi,1),%edi
      3e:	00 00 

(The bizarre nop leal instructions are generated by the assembler to
get the loop aligned right.  Ignore them.)

The `fldz' at 9 pushes the value of `sum' on the FP stack.  That stack
register is where `sum' lives.  However, since we don't know the value
of TOP upon function entry, we don't know which physical register that
is.  So GCC can't use physical FP register numbers to communicate the
variable's location to GDB.

At different points in the function, the stack will have different
depths.  From b to 20, `sum' is in ST(0).  But at 20 we push a[i] on
the stack, so `sum' is now in ST(1).  At 29 we add the product into
`sum', and pop it off the stack, so from 2b to 31, `sum' is in ST(0)
again.

I should be able to step through this function, one instruction at a
time, and print `sum' correctly at each point.  But whether GDB should
fetch ST(0) or ST(1) depends on where I am in the code.

Note that there is no "frame pointer" for the FP stack.  If I hit a
breakpoint in the middle of the function, GDB has no way of knowing
what TOP was at function entry.

GDB could figure this out by disassembling the instruction stream and
looking for FP instructions, but that's a pain.  GCC always knows how
to find the variables, of course, but it doesn't include its knowledge
in the debug info.

Re: IA32: printing FP register variables

[Jim Blandy]

So, here's the question I asked and the response I got from SCO's
compiler fellow (I assume):

Jim> Could you ask your compiler/debugger guys how their compilers
Jim> number the IA32 FP registers?  If they assign a fixed register
Jim> number to each ST(i), could you ask them how the debugger finds
Jim> the right ST(i) for a given variable while the stack is being
Jim> pushed and popped?  That is, a variable which lives in ST(4) at
Jim> one point will find itself in ST(6) after two FLD instructions,
Jim> and in ST(5) after an FADDP.  How would the debugger find the
Jim> variable at each point?  Or does the debugger just lose when
Jim> there are intermediate values on the FP stack?

"SCF" == "SCO's compiler fellow", who apparently doesn't want his real
name on public mailing lists:

SCF> Well, I don't have a good answer for you.  Our compiler basically
SCF> puts out information for the stack location of an automatic
SCF> floating-point variable.  It does not trace the location as it
SCF> moves to the floating-point stack.  As you say, the debugger
SCF> "just loses" when there are intermediate values on the FP stack.
SCF> I suppose you could use DWARF2 location lists to track the
SCF> variable with each floating-point push/pop.

So I guess nobody does this right.  Heh.  I thought so.

Re: IA32: printing FP register variables

[Robert Lipe]

>   > Hmm.  What other IA32 compilers produce STABS?  How do they number FP
>   > registers?
> Dunno.  Robert -- can you see what the SCO compilers do with this stuff?
> That might be interesting.

I know of zero SCO-supplied compilers that produce stabs.  There are
tools that do COFF (a.k.a. SDB) and tools that do ELF (dwarf-1 and
dwarf-2).  Is the really stab-specific, or do you want to know in
general how they're numbered in whatever format is used?

Since I speak no debugging formats and I speak zero floating point I'll
have to dig for an answer.   If, OTOH, there's some program I can build 
that'll help answer the question, shoot it my way.

RJL

Re: IA32: printing FP register variables

[Jim Blandy]

> Assuming no register deaths, so there's no popping to add to the
> confusion, this will ultimately get transformed to
> 
> 	fadd	%st(1)
> 	fxch	%st(2)
> 	fadd	%st(3)
> 
> Since there's no popping, the base of the FP stack has not changed.
> However, f2 and f0 were swapped, so that f2 would be at the top of
> the stack, so that we can perform the second operation.
> 
> That's not to say that you can't use the FP base to eliminate the
> need to encode the pushes and pops into the debug information, but
> you can't get away from bazillions of live ranges.

If you don't know the base of the FP stack, you have to start a new
range at each push, pop, or exchange.  If you do know the base, you
only need to start a new range at an exchange.

So you're right --- the design of the IA32 FPU requires that variables
change homes pretty frequently.  So LRS is necessary.  But numbering
registers relative to the FP stack base will still reduce the number
of ranges substantially, won't it?

Re: IA32: printing FP register variables

[Jim Blandy]

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.

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < np673tsfcd.fsf@zwingli.cygnus.com >you write:
  > 
  > > 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).
  > 
  > I wonder if it's a good idea to abuse blocks this way.  If the user
  > has a function like this:
  > 
  >     foo ()
  >     {
  >       {
  > 	int a;
  > 	...
  >       }
  >       {
  > 	int a;
  > 	...
  >       }
  >     }
  > 
  > and, while control is in the first inner block, asks the debugger to
  > monitor the value of 'a' as he steps, it would be nice if the debugger
  > could tell that the 'a' in the second block is actually a different
  > variable, and is not the one the user asked about.
Yes.  This is the only design issue I remember anyone raising for
debugging LRS code via block scopes.

It's an issue I'm willing to punt on for now if we could get the block
scope stuff to work though -- the block scope LRS stuff is very portable
if we could deal with the technical issues in the compiler.

One possibility might be to try and use the dwarf2 LRS stuff as the
first option, then the stabs LRS stuff as a secondary option, then fall
back on block scopes for any remaining cases (or if we're trying to avoid
using any stabs extensions).

  > If you use blocks the way you suggest, I'm not sure how GDB could tell
  > the difference between two separate variables with the same name, and
  > a single variable which exists in two blocks created to capture
  > different life ranges.
Without some kind of annotation I do not see a way to deal with this
problem either.

  > The STABS LRS stuff, while quirky, doesn't have this problem.
If you had the opportunity to redesign the stabs LRS stuff, what would you
recommend?  One possibility would be to try and model it strictly like
ELF works.  I do not know how feasible that would be.

It would be nice to finally hash through these issues as I'd like to 
contribute Cygnus's LRS code to egcs in the near future.

jeff

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < 00d401beca31$3d752c10$3404010a@metrowerks.com >you write:
  > 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.
I believe dwarf2 is expressive enough to handle all this stuff.   It's just
a matter of coding up the support we need in gcc & gdb to utilize the dwarf2
features in an appropriate manner.


jeff

Re: IA32: printing FP register variables

[Jim Blandy]

> I think you get more stable position designations by considering the
> position relative to the bottom of the stack.

True, but the whole problem is that we don't have any kind of frame
pointer for the FP stack, so we can't map from a bottom-relative
register number to a physical register number.  As Ben points out, you
can guess the bottom from the tags, but not reliably.

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < np908ljwht.fsf@zwingli.cygnus.com >you write:
  > 
  > Hmm.  What other IA32 compilers produce STABS?  How do they number FP
  > registers?
Dunno.  Robert -- can you see what the SCO compilers do with this stuff?
That might be interesting.

  > If GDB can find the base of the FP stack reliably, using the method
  > that Ben Combee suggests, then we don't need LRS at all to describe
  > variables' homes.  If we simply number the FP registers relative to
  > the base of the FP stack, their names won't change as insns push and
  > pop FP values.
I'm not sure this is safe either.  Consider what happens at basic block
boundaries to the regstack.   I believe variables location relative to 
the bottom of the stack can change at a basic block boundary.
jeff

Re: IA32: printing FP register variables

[Jim Blandy]

> On Mon, Jul 19, 1999 at 03:26:18PM -0500, Jim Blandy wrote:
> > Once the other internal work is done, would the EGCS folks be willing
> > to experiment with both, and give us some sense of how much difference
> > it makes?
> 
> Yes.  It seems a reasonable thing to try.

Okay.  So the current plan is:

1) EGCS folks get regstack to actually propagate the variable/register
   mapping to its output accurately.
2) EGCS folks make sure accurate LRS information is generated.
3) EGCS folks compare output size using base-relative and top-relative
   numberings.  Unless the space savings are persuasive, we stick with
   the more intuitive and more widely used top-relative numbering.
4) Once EGCS is generating the information correctly, GDB folks implement
   support for whatever numbering system the EGCS folks recommend.

Re: IA32: printing FP register variables

[Jim Blandy]

> 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.

That could work, but what if you happen to have all eight registers in
use?

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < 199907090356.WAA01337@zwingli.cygnus.com >you write:
  > On IA32 processors, how should GDB find the values of variables which
  > live in floating-point registers?  At the moment, it can't do this
  > reliably, which must be a royal pain for people doing numeric work.
To say the least :-)  It's not just folks doing numeric work -- it's a 
pain for those of us who have to analyze bug reports on ia32 which perform
FP computations ;-)


  > What does the register number which GCC emits now mean?  If an N_RSYM
  > stab has a value of 8, what does that mean?  ST(0)?  When?  Every
  > variable is ST(0) when it's just been pushed.
I have some guesses about what it might mean ;-)

gcc works by initially pretending it has a flat register file with 8 FP regs.
It assigns user variables, temporaries, etc to those 8 FP regs.  I suspect
the number gcc emits corresponds to the index into the flat register file.

After allocation is finished, gcc converts the flat register file into a 
stacked register file.  I do not think it tries to update any debug info
when converting to a stacked register file.

I believe gcc will have to emit more debug info for gdb to be able to find
FP variables on the regstack.


  > Should GDB derive this info on its own?  It could disassemble the
  > function, starting from the end of the prologue, and count pushes and
  > pops, building a table mapping PC values onto stack depths.  (This
  > assumes that the stack depth is constant at a given PC.)  That would
  > require no debug info, but would be a pain to implement.
Not only would it be a pain, I believe gcc already has this information handy,
just not in a good place for emitting debugging symbols.
jeff

Re: IA32: printing FP register variables

[Jim Blandy]

> > 1) EGCS folks get regstack to actually propagate the variable/register
> >    mapping to its output accurately.
> 
> Yes, this is a reasonable plan.  As to a time frame... I don't know.

We have no customer complaining about this.  So there's no external
pressure.  It's just lame when GDB can't reliably print `foo'.

Re: IA32: printing FP register variables

[Ben Combee]

> > 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.

Re: IA32: printing FP register variables

[Jim Blandy]

So, here's the question I asked and the response I got from SCO's
compiler fellow (I assume):

Jim> Could you ask your compiler/debugger guys how their compilers
Jim> number the IA32 FP registers?  If they assign a fixed register
Jim> number to each ST(i), could you ask them how the debugger finds
Jim> the right ST(i) for a given variable while the stack is being
Jim> pushed and popped?  That is, a variable which lives in ST(4) at
Jim> one point will find itself in ST(6) after two FLD instructions,
Jim> and in ST(5) after an FADDP.  How would the debugger find the
Jim> variable at each point?  Or does the debugger just lose when
Jim> there are intermediate values on the FP stack?

"SCF" == "SCO's compiler fellow", who apparently doesn't want his real
name on public mailing lists:

SCF> Well, I don't have a good answer for you.  Our compiler basically
SCF> puts out information for the stack location of an automatic
SCF> floating-point variable.  It does not trace the location as it
SCF> moves to the floating-point stack.  As you say, the debugger
SCF> "just loses" when there are intermediate values on the FP stack.
SCF> I suppose you could use DWARF2 location lists to track the
SCF> variable with each floating-point push/pop.

So I guess nobody does this right.  Heh.  I thought so.

Re: IA32: printing FP register variables

[Jim Blandy]

> > See what 'z' looks like in the debug records.  It might be helpful to include
> > the entire assembly file since we'll also need to verify that 'z' ended up in
> > an FP reg.
> 
> I feel I'd be doing you a disservice in trying to interpret these
> since I know nothing about floating point and nothing about debugging
> records.  I'll report the results from any tests that you find useful,
> though.  I'm also not afraid to drag SCO's compiler dudes into private
> conversations for things like this but they've promised to kill me if I
> mention their names in the public lists. :-)  
> 
> I fed that snippet into the pertinent compilers that I had ready access
> to.  I've attached a tarball of the resulting .s files.  Here's the
> secret spy decoder ring.  The last one is dwarf-2 and should match
> what's shipped as the UDK and SVR5 (i.e. UnixWare 7) . The ELF ones are
> dwarf-1.
> 
>         icc -bcoff -S -g j.c ; mv j.s icc_coff.s
>         icc -belf -S -g j.c ; mv j.s icc_elf.s
>         /bin/cc -bcoff -S -g j.c ; mv j.s cc_coff.s
>         /bin/cc -belf -S -g j.c ; mv j.s cc_elf.s
>         /udk/usr/ccs/bin/cc -S -g j.c ; mv j.s svr5_elf.s
> 
> Stir in a few native GCC chains, the ancient Microsoft/XENIX tools, and
> some MIPS-cross stuff that I have laying around and you see that I live
> in an embarrassment of compiler poverty. :-)

That's a nice menagerie you've got there.

Unfortunately, these files don't contain enough information to tell
exactly how those compilers assign numbers to FP registers, or how the
debugger actually finds the value.

Could you ask your compiler/debugger guys how their compilers number
the IA32 FP registers?  If they assign a fixed register number to each
ST(i), could you ask them how the debugger finds the right ST(i) for a
given variable while the stack is being pushed and popped?  That is, a
variable which lives in ST(4) at one point will find itself in ST(6)
after two FLD instructions, and in ST(5) after an FADDP.  How would
the debugger find the variable at each point?  Or does the debugger
just lose when there are intermediate values on the FP stack?

Re: IA32: printing FP register variables

[Jim Blandy]

> > 1) EGCS folks get regstack to actually propagate the variable/register
> >    mapping to its output accurately.
> 
> Yes, this is a reasonable plan.  As to a time frame... I don't know.

We have no customer complaining about this.  So there's no external
pressure.  It's just lame when GDB can't reliably print `foo'.

Re: IA32: printing FP register variables

[Jim Blandy]

Would it be possible to re-derive some of the LRS info by analyzing
the final code?  The less information you need to carry through the
optimizations, the better, it seems to me.

Re: IA32: printing FP register variables

[Richard Henderson]

On Mon, Jul 26, 1999 at 01:42:41PM -0500, Jim Blandy wrote:
> Okay.  So the current plan is:
> 
> 1) EGCS folks get regstack to actually propagate the variable/register
>    mapping to its output accurately.

Yes, this is a reasonable plan.  As to a time frame... I don't know.

What we need is a good infrastructure for handling LRS debug info in
a convenient form within the compiler.  Whether this gets emitted as
dwarf2 location ranges, or stabs live ranges, or as a set of virtual
lexical blocks.  What Cygnus has now for LRS just won't work when the
size live ranges are on the order of instructions.

If someone has brilliant ideas how to manage and manipulate this stuff
in a way that won't make things an absolute nightmare, I'd be glad to
hear it.

I'll throw out one idea -- live ranges must always begin with a store.
What if we put a REG_START_RANGE in places that a user variable moves
to a new location.  And a REG_END_RANGE note in places a user variable
truely dies and its register gets re-allocated to some temp.  The value
of the note would be some canonical token that lets us match up with
the DECL in question.

Just before, or in the process of, emitting debug info, we use the
CFG and the REG_*_RANGE notes to transform this somewhat fluid form
into something that the debugger can use.

A particularly major open issue is how the optimizers can easily know
when they need to create these notes, and which variables the notes 
are being created for.  I could easily see it being a not insignificant
task to find this, given that it's all scattered about.  But the fact
that it's scattered about is crucial to being resiliant against
ever-changing insn sequences.

The extra memory and time might even call for it only being enabled
at -g3 or something.  Something we'll have to examine.

Thoughts?



r~

Re: IA32: printing FP register variables

[Jim Blandy]

> On Mon, Jul 19, 1999 at 03:26:18PM -0500, Jim Blandy wrote:
> > Once the other internal work is done, would the EGCS folks be willing
> > to experiment with both, and give us some sense of how much difference
> > it makes?
> 
> Yes.  It seems a reasonable thing to try.

Okay.  So the current plan is:

1) EGCS folks get regstack to actually propagate the variable/register
   mapping to its output accurately.
2) EGCS folks make sure accurate LRS information is generated.
3) EGCS folks compare output size using base-relative and top-relative
   numberings.  Unless the space savings are persuasive, we stick with
   the more intuitive and more widely used top-relative numbering.
4) Once EGCS is generating the information correctly, GDB folks implement
   support for whatever numbering system the EGCS folks recommend.

Re: IA32: printing FP register variables

[Richard Henderson]

On Mon, Jul 19, 1999 at 03:26:18PM -0500, Jim Blandy wrote:
> Once the other internal work is done, would the EGCS folks be willing
> to experiment with both, and give us some sense of how much difference
> it makes?

Yes.  It seems a reasonable thing to try.


r~

Re: IA32: printing FP register variables

[Jim Blandy]

The disadvantages of base-relative numbering are:
- It's unexpected.  Every existing system saves registers in
  top-relative order.  The IA32's FSAVE instruction saves them
  top-relative.  Assembly code refers to them top-relative.
- I'm not sure how to implement something like "print $st0".
- It requires straightforward but non-trivial support in GDB's
  target-specific code to find the FP stack base and load the register
  array properly.

In that light, it had better save us a significant amount of space
over top-relative numbering if we're going to go to the trouble.  But
we have no idea how much space it will save.

Once the other internal work is done, would the EGCS folks be willing
to experiment with both, and give us some sense of how much difference
it makes?

If the savings are negligible, I'm not sure it's worth the hair.

Re: IA32: printing FP register variables

[Richard Henderson]

On Tue, Jul 13, 1999 at 03:25:02PM -0500, Jim Blandy wrote:
> But numbering registers relative to the FP stack base will still reduce
> the number of ranges substantially, won't it?

Yes.


r~

Re: IA32: printing FP register variables

[Jim Blandy]

I hope that I'm not mixing up my priorities by worrying about debug
size.  But since a register numbering is a matter of public protocol,
it will be more trouble to change it later than to make a good choice
now.

There are only three possible numberings that make any sense:
physical, top-relative, or base-relative.

Physical is not possible, since the compiler doesn't know the value of
TOP at function entry.

top-relative is, I think we all agree, the least stable of all
possible orderings.

So base-relative is what we have left.  We will still require LRS info
in almost every case, but it's better than the alternatives.

If GCC will have trouble generating base-relative register numbers
(if, for example, regstack has no concept of the FP stack base), then
that would tip the scales.  If someone can find an i386 STABS system
that uses another numbering, that would too.

Re: IA32: printing FP register variables

[Jim Blandy]

> Assuming no register deaths, so there's no popping to add to the
> confusion, this will ultimately get transformed to
> 
> 	fadd	%st(1)
> 	fxch	%st(2)
> 	fadd	%st(3)
> 
> Since there's no popping, the base of the FP stack has not changed.
> However, f2 and f0 were swapped, so that f2 would be at the top of
> the stack, so that we can perform the second operation.
> 
> That's not to say that you can't use the FP base to eliminate the
> need to encode the pushes and pops into the debug information, but
> you can't get away from bazillions of live ranges.

If you don't know the base of the FP stack, you have to start a new
range at each push, pop, or exchange.  If you do know the base, you
only need to start a new range at an exchange.

So you're right --- the design of the IA32 FPU requires that variables
change homes pretty frequently.  So LRS is necessary.  But numbering
registers relative to the FP stack base will still reduce the number
of ranges substantially, won't it?

Re: IA32: printing FP register variables

[Richard Henderson]

On Mon, Jul 12, 1999 at 06:09:50PM -0500, Jim Blandy wrote:
> If GDB can find the base of the FP stack reliably, using the method
> that Ben Combee suggests, then we don't need LRS at all to describe
> variables' homes.  If we simply number the FP registers relative to
> the base of the FP stack, their names won't change as insns push and
> pop FP values.

You can find the base of the stack, it's true.  But that does you
no good whatsoever. 

Consider the following sequence:

	(set (reg f0) (add (reg f0) (reg f1)))
	(set (reg f2) (add (reg f2) (reg f3)))

Assuming no register deaths, so there's no popping to add to the
confusion, this will ultimately get transformed to

	fadd	%st(1)
	fxch	%st(2)
	fadd	%st(3)

Since there's no popping, the base of the FP stack has not changed.
However, f2 and f0 were swapped, so that f2 would be at the top of
the stack, so that we can perform the second operation.

That's not to say that you can't use the FP base to eliminate the
need to encode the pushes and pops into the debug information, but
you can't get away from bazillions of live ranges.


r~

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < 19990712191723.E3871@rjlhome.sco.com >you write:
  > >   > Hmm.  What other IA32 compilers produce STABS?  How do they number FP
  > >   > registers?
  > > Dunno.  Robert -- can you see what the SCO compilers do with this stuff?
  > > That might be interesting.
  > 
  > I know of zero SCO-supplied compilers that produce stabs.  There are
  > tools that do COFF (a.k.a. SDB) and tools that do ELF (dwarf-1 and
  > dwarf-2).  Is the really stab-specific, or do you want to know in
  > general how they're numbered in whatever format is used?
The general case would be good to know as a starting point.  Particularly
what gets inencoded into the register # field in the dwarf records.

  > Since I speak no debugging formats and I speak zero floating point I'll
  > have to dig for an answer.   If, OTOH, there's some program I can build 
  > that'll help answer the question, shoot it my way.
Not really.  I suspect you could probably take just about anything with a few
FP ops from the gcc testsuite as a sample program.

jeff

Re: IA32: printing FP register variables

[Joern Rennecke]

> Consider two threads of control, each with one variable on the FP stack.
> 
> At some point they merge.  One variable has to be on the bottom, the other
> on the top.
> 
> regstack has to track this stuff and emit appropriate code at block boundaries
> to move stuff around via copies.

Currently, flow will consider both variables live in the predecessor blocks
if they are live in the successor block.  We'd need better data & control
flow analysis to find cases where a varaible is indeed live only in a
subset of the predecessor blocks.

So I guess that you are talking about the case when the variables were
allocated in different positions in the register stack in the different
predecessor blocks.  That means that the number of live registers in the
FP stack doesn't change at the basic block boundary, but but the positions of
two or more variables change.  Since the stack usage stays the same,
the number of variables that change location is the same no matter if
we count from the top or from the bottom of the stack.
We'll have to emit enough debugging information as it takes then to
describe all these position changes.

Re: IA32: printing FP register variables

[Robert Lipe]

>   > Hmm.  What other IA32 compilers produce STABS?  How do they number FP
>   > registers?
> Dunno.  Robert -- can you see what the SCO compilers do with this stuff?
> That might be interesting.

I know of zero SCO-supplied compilers that produce stabs.  There are
tools that do COFF (a.k.a. SDB) and tools that do ELF (dwarf-1 and
dwarf-2).  Is the really stab-specific, or do you want to know in
general how they're numbered in whatever format is used?

Since I speak no debugging formats and I speak zero floating point I'll
have to dig for an answer.   If, OTOH, there's some program I can build 
that'll help answer the question, shoot it my way.

RJL

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < 199907122349.AAA25740@phal.cygnus.co.uk >you write:
  > > I'm not sure this is safe either.  Consider what happens at basic block
  > > boundaries to the regstack.   I believe variables location relative to 
  > > the bottom of the stack can change at a basic block boundary.
  > 
  > Huh?  Why that?  The FPU doesn't know about the control flow.
Consider two threads of control, each with one variable on the FP stack.

At some point they merge.  One variable has to be on the bottom, the other
on the top.

regstack has to track this stuff and emit appropriate code at block boundaries
to move stuff around via copies.

It is also why I believe an LCM based copy propagation algorithm can be used
to improve the code generated by regstack.


jeff

Re: IA32: printing FP register variables

[Joern Rennecke]

> I'm not sure this is safe either.  Consider what happens at basic block
> boundaries to the regstack.   I believe variables location relative to 
> the bottom of the stack can change at a basic block boundary.

Huh?  Why that?  The FPU doesn't know about the control flow.

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < np908ljwht.fsf@zwingli.cygnus.com >you write:
  > 
  > Hmm.  What other IA32 compilers produce STABS?  How do they number FP
  > registers?
Dunno.  Robert -- can you see what the SCO compilers do with this stuff?
That might be interesting.

  > If GDB can find the base of the FP stack reliably, using the method
  > that Ben Combee suggests, then we don't need LRS at all to describe
  > variables' homes.  If we simply number the FP registers relative to
  > the base of the FP stack, their names won't change as insns push and
  > pop FP values.
I'm not sure this is safe either.  Consider what happens at basic block
boundaries to the regstack.   I believe variables location relative to 
the bottom of the stack can change at a basic block boundary.
jeff

Re: IA32: printing FP register variables

[Jim Blandy]

Hmm.  What other IA32 compilers produce STABS?  How do they number FP
registers?

If GDB can find the base of the FP stack reliably, using the method
that Ben Combee suggests, then we don't need LRS at all to describe
variables' homes.  If we simply number the FP registers relative to
the base of the FP stack, their names won't change as insns push and
pop FP values.

So the only work to be done is:
- GCC needs to propage the register/variable association through the
  stackifier, so it can produce coherent debug output.
- GDB needs to use Ben Combee's tactic for finding the base of the
  stack.

Re: IA32: printing FP register variables

[David Edelsohn]

>>>>> Philipp Thomas writes:

Philipp> Sorry for jumping in, but does anybody know *why* intel did that
Philipp> braindamage, i.e. designed the original 8087 using a stack instead of
Philipp> memory mapped registers? I remember once playing with a Weitek (costly
Philipp> little beasts :), which did offer memory mapped access and that was
Philipp> noticeably faster than the stack.

	Advice from IBM -- precursor to register window research.

David

Re: IA32: printing FP register variables

[Philipp Thomas]

On Sat, 10 Jul 1999 17:09:56 -0600, Jeffrey A Law <law@cygnus.com>
wrote:

>However, we need to keep in mind this is only an issue for the x86.  No other
>port has this kind of braindamage.

Sorry for jumping in, but does anybody know *why* intel did that
braindamage, i.e. designed the original 8087 using a stack instead of
memory mapped registers? I remember once playing with a Weitek (costly
little beasts :), which did offer memory mapped access and that was
noticeably faster than the stack.

Only for the Ia64 it seems like they finally did it right. But as it
was a totally new architecture, they could probably throw away the
stack model more easily.

Philipp

-- 
You have moved your mouse. Windows must be rebooted for the
changes to take effect.

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < np673tsfcd.fsf@zwingli.cygnus.com >you write:
  > 
  > > 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).
  > 
  > I wonder if it's a good idea to abuse blocks this way.  If the user
  > has a function like this:
  > 
  >     foo ()
  >     {
  >       {
  > 	int a;
  > 	...
  >       }
  >       {
  > 	int a;
  > 	...
  >       }
  >     }
  > 
  > and, while control is in the first inner block, asks the debugger to
  > monitor the value of 'a' as he steps, it would be nice if the debugger
  > could tell that the 'a' in the second block is actually a different
  > variable, and is not the one the user asked about.
Yes.  This is the only design issue I remember anyone raising for
debugging LRS code via block scopes.

It's an issue I'm willing to punt on for now if we could get the block
scope stuff to work though -- the block scope LRS stuff is very portable
if we could deal with the technical issues in the compiler.

One possibility might be to try and use the dwarf2 LRS stuff as the
first option, then the stabs LRS stuff as a secondary option, then fall
back on block scopes for any remaining cases (or if we're trying to avoid
using any stabs extensions).

  > If you use blocks the way you suggest, I'm not sure how GDB could tell
  > the difference between two separate variables with the same name, and
  > a single variable which exists in two blocks created to capture
  > different life ranges.
Without some kind of annotation I do not see a way to deal with this
problem either.

  > The STABS LRS stuff, while quirky, doesn't have this problem.
If you had the opportunity to redesign the stabs LRS stuff, what would you
recommend?  One possibility would be to try and model it strictly like
ELF works.  I do not know how feasible that would be.

It would be nice to finally hash through these issues as I'd like to 
contribute Cygnus's LRS code to egcs in the near future.

jeff

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < np908psfqu.fsf@zwingli.cygnus.com >you write:
  > Okay, but do you really want to emit up to eight stabs at every FP
  > instruction that changes the stack?
If that's what it takes to get access to FP variables, yes.

Another option would be to set up a stack in the debug symbols and
push/pop the debug symbol stack in a manner similar to what we do with
the actual FP regstack.  There's some serious issues with how we do this
portably, but it's worth thinking about.

  > I dunno --- maybe it's not a big deal.  It may not be worth creating a
  > whole new form of debugging info to save that space.  It is certainly
  > a problem the various LRS representations handle.  I'd certainly agree
  > we should try it first.
Compactness of debug symbols hasn't ever been a serious concern.  At some
point it will need to be addressed though.

However, we need to keep in mind this is only an issue for the x86.  No other
port has this kind of braindamage.

jeff

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < np3dyxu2ua.fsf@zwingli.cygnus.com >you write:
  > 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.
Correct.  While the MMX registers are overloaded on the FPU registers, 
they do not stack like FP operations do.

  > 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.
Precisely.

jeff

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < npbtdlsg2i.fsf@zwingli.cygnus.com >you write:
  > In code generated by your compiler, is the value of TOP (the three-bit
  > FPU stack pointer) at function entry known at compile time?  Or does
  > its value depend on the caller, and the caller's caller, etc.?
Aren't all the FP registers on the x86 considered call-clobbered?  If
so, then there should be no FP regs live across a function call.

With that in mind, the state of the FP stack ought to be empty at the
start of each function.

Or am I missing something?  I'm not really an ia32 guru.

jeff

Re: IA32: printing FP register variables

[Jim Blandy]

> Then the scan code sees that there are no empty registers, so the eighth
> register is the bottom of the stack.  The IA32 FPU itself uses this logic --
> if you push something on the stack such that TOP gets incremented to point
> to a non-empty value, you get a stack overflow.

Right --- of course.  That would work.  So we could use bottom-relative
register numbers.

Re: IA32: printing FP register variables

[Jim Blandy]

> I think you get more stable position designations by considering the
> position relative to the bottom of the stack.

True, but the whole problem is that we don't have any kind of frame
pointer for the FP stack, so we can't map from a bottom-relative
register number to a physical register number.  As Ben points out, you
can guess the bottom from the tags, but not reliably.

Re: IA32: printing FP register variables

[Jim Blandy]

> 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).

I wonder if it's a good idea to abuse blocks this way.  If the user
has a function like this:

    foo ()
    {
      {
	int a;
	...
      }
      {
	int a;
	...
      }
    }

and, while control is in the first inner block, asks the debugger to
monitor the value of 'a' as he steps, it would be nice if the debugger
could tell that the 'a' in the second block is actually a different
variable, and is not the one the user asked about.

If you use blocks the way you suggest, I'm not sure how GDB could tell
the difference between two separate variables with the same name, and
a single variable which exists in two blocks created to capture
different life ranges.

The STABS LRS stuff, while quirky, doesn't have this problem.

Re: IA32: printing FP register variables

[Joern Rennecke]

> Okay, but do you really want to emit up to eight stabs at every FP
> instruction that changes the stack?

Well, if the bottom of stack - relative information is workable, I'd prefer
that.
I suppose you can detect the eight-registers-used situation by noting that
there is no empty register.

Re: IA32: printing FP register variables

[Ben Combee]

> > 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.
>
> That could work, but what if you happen to have all eight registers in
> use?

Then the scan code sees that there are no empty registers, so the eighth
register is the bottom of the stack.  The IA32 FPU itself uses this logic --
if you push something on the stack such that TOP gets incremented to point
to a non-empty value, you get a stack overflow.

Of course, all this is also based on the assumption, explicit in the Win32
ABI, that the FPU stack is empty on entry to a function.  I think this holds
for the x86 Linux ABI as well -- I can't see any logical other way to do it
since you don't generally know how many levels of nesting there are when
your function is called.

Re: IA32: printing FP register variables

[Jim Blandy]

> > 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).

Okay, but do you really want to emit up to eight stabs at every FP
instruction that changes the stack?

I dunno --- maybe it's not a big deal.  It may not be worth creating a
whole new form of debugging info to save that space.  It is certainly
a problem the various LRS representations handle.  I'd certainly agree
we should try it first.

Re: IA32: printing FP register variables

[Jim Blandy]

> 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.

That could work, but what if you happen to have all eight registers in
use?

Re: IA32: printing FP register variables

[Jim Blandy]

I'm sorry, Ben, but I'm still confused about how you find the FP
register containing a variable.  I think there's a fundamental,
difficult problem here which you don't seem to be mentioning at all.
Perhaps you have solved it already, and assume we have too.

In code generated by your compiler, is the value of TOP (the three-bit
FPU stack pointer) at function entry known at compile time?  Or does
its value depend on the caller, and the caller's caller, etc.?

For a function like this:

    double
    dot_product (int n, double *a, double *b)
    {
      int i;
      double sum = 0;

      for (i = 0; i < n; i++)
	sum += a[i] * b[i];

      return sum;
    }

EGCS generates code like this:

    00000000 <dot_product>:
       0:	55             	pushl  %ebp
       1:	31 c0          	xorl   %eax,%eax
       3:	89 e5          	movl   %esp,%ebp
       5:	53             	pushl  %ebx
       6:	8b 5d 08       	movl   0x8(%ebp),%ebx
       9:	d9 ee          	fldz   
       b:	8b 4d 0c       	movl   0xc(%ebp),%ecx
       e:	8b 55 10       	movl   0x10(%ebp),%edx
      11:	39 d8          	cmpl   %ebx,%eax
      13:	7d 18          	jnl    2d <dot_product+0x2d>
      15:	8d 74 26 00    	leal   0x0(%esi,1),%esi
      19:	8d bc 27 00 00 	leal   0x0(%edi,1),%edi
      1e:	00 00 
      20:	dd 04 c1       	fldl   (%ecx,%eax,8)
      23:	dc 0c c2       	fmull  (%edx,%eax,8)
      26:	40             	incl   %eax
      27:	39 d8          	cmpl   %ebx,%eax
      29:	de c1          	faddp  %st,%st(1)
      2b:	7c f3          	jl     20 <dot_product+0x20>
      2d:	5b             	popl   %ebx
      2e:	89 ec          	movl   %ebp,%esp
      30:	5d             	popl   %ebp
      31:	c3             	ret    
      32:	8d b4 26 00 00 	leal   0x0(%esi,1),%esi
      37:	00 00 
      39:	8d bc 27 00 00 	leal   0x0(%edi,1),%edi
      3e:	00 00 

(The bizarre nop leal instructions are generated by the assembler to
get the loop aligned right.  Ignore them.)

The `fldz' at 9 pushes the value of `sum' on the FP stack.  That stack
register is where `sum' lives.  However, since we don't know the value
of TOP upon function entry, we don't know which physical register that
is.  So GCC can't use physical FP register numbers to communicate the
variable's location to GDB.

At different points in the function, the stack will have different
depths.  From b to 20, `sum' is in ST(0).  But at 20 we push a[i] on
the stack, so `sum' is now in ST(1).  At 29 we add the product into
`sum', and pop it off the stack, so from 2b to 31, `sum' is in ST(0)
again.

I should be able to step through this function, one instruction at a
time, and print `sum' correctly at each point.  But whether GDB should
fetch ST(0) or ST(1) depends on where I am in the code.

Note that there is no "frame pointer" for the FP stack.  If I hit a
breakpoint in the middle of the function, GDB has no way of knowing
what TOP was at function entry.

GDB could figure this out by disassembling the instruction stream and
looking for FP instructions, but that's a pain.  GCC always knows how
to find the variables, of course, but it doesn't include its knowledge
in the debug info.

Re: IA32: printing FP register variables

[Ben Combee]

> > 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/

Re: IA32: printing FP register variables

[Joern Rennecke]

> 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).

Re: IA32: printing FP register variables

[Jim Blandy]

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.

Re: IA32: printing FP register variables

[Jim Blandy]

> 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.

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < 00d401beca31$3d752c10$3404010a@metrowerks.com >you write:
  > 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.
I believe dwarf2 is expressive enough to handle all this stuff.   It's just
a matter of coding up the support we need in gcc & gdb to utilize the dwarf2
features in an appropriate manner.


jeff

Re: IA32: printing FP register variables

[Ben Combee]

> > 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.

Re: IA32: printing FP register variables

[Joern Rennecke]

> 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.

Re: IA32: printing FP register variables

[Michael Meissner]

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

Re: IA32: printing FP register variables

[Jeffrey A Law]

  In message < 199907090356.WAA01337@zwingli.cygnus.com >you write:
  > On IA32 processors, how should GDB find the values of variables which
  > live in floating-point registers?  At the moment, it can't do this
  > reliably, which must be a royal pain for people doing numeric work.
To say the least :-)  It's not just folks doing numeric work -- it's a 
pain for those of us who have to analyze bug reports on ia32 which perform
FP computations ;-)


  > What does the register number which GCC emits now mean?  If an N_RSYM
  > stab has a value of 8, what does that mean?  ST(0)?  When?  Every
  > variable is ST(0) when it's just been pushed.
I have some guesses about what it might mean ;-)

gcc works by initially pretending it has a flat register file with 8 FP regs.
It assigns user variables, temporaries, etc to those 8 FP regs.  I suspect
the number gcc emits corresponds to the index into the flat register file.

After allocation is finished, gcc converts the flat register file into a 
stacked register file.  I do not think it tries to update any debug info
when converting to a stacked register file.

I believe gcc will have to emit more debug info for gdb to be able to find
FP variables on the regstack.


  > Should GDB derive this info on its own?  It could disassemble the
  > function, starting from the end of the prologue, and count pushes and
  > pops, building a table mapping PC values onto stack depths.  (This
  > assumes that the stack depth is constant at a given PC.)  That would
  > require no debug info, but would be a pain to implement.
Not only would it be a pain, I believe gcc already has this information handy,
just not in a good place for emitting debugging symbols.
jeff

Re: IA32: printing FP register variables

[Jeffrey A Law]

  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.

jeff
dbxout.c 
clean manner 
same mechanisms 


  > 
  > --
  > Ben Combee, x86/Win32/Novell/Linux CompilerWarrior
  > http://www.metrowerks.com/
  > ----- Original Message -----
  > From: Jim Blandy <jimb@cygnus.com>
  > To: <egcs@egcs.cygnus.com>; <gdb@sourceware.cygnus.com>
  > Sent: Thursday, July 08, 1999 10:56 PM
  > Subject: IA32: printing FP register variables
  > 
  > 
  > >
  > > This is a question about how GDB should grok code produced by GCC, so
  > > I'm posting it to both lists.
  > >
  > > On IA32 processors, how should GDB find the values of variables which
  > > live in floating-point registers?  At the moment, it can't do this
  > > reliably, which must be a royal pain for people doing numeric work.
  > >
  > > It's a non-trivial problem.  GCC simply places the variables on the
  > > top of the FP stack, so which physical FP registers receive them
  > > depends on the value of the floating-point stack pointer upon entry to
  > > the function.  And since GCC uses the floating-point stack to hold
  > > temporary values, a variable's offset from the stack pointer changes
  > > as the function executes.
  > >
  > > This makes it difficult for GDB to find a variable's value as the
  > > function executes.  In order to find a variable, it needs to know how
  > > many intermediate results are presently above it on the stack.  GCC
  > > knows this, but doesn't give GDB any hints about it in the debugging
  > > info.
  > >
  > > What does the register number which GCC emits now mean?  If an N_RSYM
  > > stab has a value of 8, what does that mean?  ST(0)?  When?  Every
  > > variable is ST(0) when it's just been pushed.
  > >
  > > Should GCC emit more debug info, to help GDB find variables?
  > >
  > > Should GDB derive this info on its own?  It could disassemble the
  > > function, starting from the end of the prologue, and count pushes and
  > > pops, building a table mapping PC values onto stack depths.  (This
  > > assumes that the stack depth is constant at a given PC.)  That would
  > > require no debug info, but would be a pain to implement.
  > >
  > 
  > 

Re: IA32: printing FP register variables

[Ben Combee]

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 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.

--
Ben Combee, x86/Win32/Novell/Linux CompilerWarrior
http://www.metrowerks.com/
----- Original Message -----
From: Jim Blandy <jimb@cygnus.com>
To: <egcs@egcs.cygnus.com>; <gdb@sourceware.cygnus.com>
Sent: Thursday, July 08, 1999 10:56 PM
Subject: IA32: printing FP register variables


>
> This is a question about how GDB should grok code produced by GCC, so
> I'm posting it to both lists.
>
> On IA32 processors, how should GDB find the values of variables which
> live in floating-point registers?  At the moment, it can't do this
> reliably, which must be a royal pain for people doing numeric work.
>
> It's a non-trivial problem.  GCC simply places the variables on the
> top of the FP stack, so which physical FP registers receive them
> depends on the value of the floating-point stack pointer upon entry to
> the function.  And since GCC uses the floating-point stack to hold
> temporary values, a variable's offset from the stack pointer changes
> as the function executes.
>
> This makes it difficult for GDB to find a variable's value as the
> function executes.  In order to find a variable, it needs to know how
> many intermediate results are presently above it on the stack.  GCC
> knows this, but doesn't give GDB any hints about it in the debugging
> info.
>
> What does the register number which GCC emits now mean?  If an N_RSYM
> stab has a value of 8, what does that mean?  ST(0)?  When?  Every
> variable is ST(0) when it's just been pushed.
>
> Should GCC emit more debug info, to help GDB find variables?
>
> Should GDB derive this info on its own?  It could disassemble the
> function, starting from the end of the prologue, and count pushes and
> pops, building a table mapping PC values onto stack depths.  (This
> assumes that the stack depth is constant at a given PC.)  That would
> require no debug info, but would be a pain to implement.
>

IA32: printing FP register variables

[Jim Blandy]

This is a question about how GDB should grok code produced by GCC, so
I'm posting it to both lists.

On IA32 processors, how should GDB find the values of variables which
live in floating-point registers?  At the moment, it can't do this
reliably, which must be a royal pain for people doing numeric work.

It's a non-trivial problem.  GCC simply places the variables on the
top of the FP stack, so which physical FP registers receive them
depends on the value of the floating-point stack pointer upon entry to
the function.  And since GCC uses the floating-point stack to hold
temporary values, a variable's offset from the stack pointer changes
as the function executes.

This makes it difficult for GDB to find a variable's value as the
function executes.  In order to find a variable, it needs to know how
many intermediate results are presently above it on the stack.  GCC
knows this, but doesn't give GDB any hints about it in the debugging
info.

What does the register number which GCC emits now mean?  If an N_RSYM
stab has a value of 8, what does that mean?  ST(0)?  When?  Every
variable is ST(0) when it's just been pushed.

Should GCC emit more debug info, to help GDB find variables?

Should GDB derive this info on its own?  It could disassemble the
function, starting from the end of the prologue, and count pushes and
pops, building a table mapping PC values onto stack depths.  (This
assumes that the stack depth is constant at a given PC.)  That would
require no debug info, but would be a pain to implement.