Mirror of the gdb mailing list
 help / color / mirror / Atom feed
  • * Re: IA32: printing FP register variables
       [not found] ` <np908ljwht.fsf@zwingli.cygnus.com>
       [not found]   ` <9209.931822541@upchuck.cygnus.com>
@ 1999-07-12 19:40   ` Richard Henderson
       [not found]     ` <np3dysi9gh.fsf@zwingli.cygnus.com>
  1 sibling, 1 reply; 16+ messages in thread
From: Richard Henderson @ 1999-07-12 19:40 UTC (permalink / raw)
  To: Jim Blandy; +Cc: law, egcs, gdb

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~
From jimb@cygnus.com Tue Jul 13 13:19:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: law@cygnus.com
Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: LRS in STABS
Date: Tue, 13 Jul 1999 13:19:00 -0000
Message-id: <np4sj8i9pp.fsf@zwingli.cygnus.com>
References: <9101.931821781@upchuck.cygnus.com>
X-SW-Source: 1999-q3/msg00062.html
Content-length: 1850

>   > I would create a new stab type, N_NEWHOME; you put as many of these as
>   > needed after an N_[RLP]SYM.  I'd use the value of the stab to indicate
>   > the beginning of the range, perhaps put the length of the range in its
>   > desc, and encode the variable's new home in the name.
>   > 
>   > STABS encodes a variable's home in the stab's type and value.  There's
>   > no prior art saying how to put the variable's home in a symbol name.
>   > But there are really only a few kinds of locations GDB can handle
>   > anyway, so this isn't too hard.
>   > 
>   > The value of an N_NEWHOME stab should be relative to the function
>   > start, to avoid creating relocs.
>   > 
>   > # The function foo gets x as a parameter on the stack at fp+4.
>   > # From .LR3 to .LR5, it lives in register 2.
>   > # From .LR6 to .LR7, it lives in register 8.
>   > .stabs "x:p1",N_PSYM,0,0,4
>   > .stabs "r2",N_NEWHOME,0,.LR5-.LR3,.LR3-foo
>   > .stabs "r8",N_NEWHOME,0,.LR7-.LR6,.LR6-foo
>   > 
>   > That seems much simpler than what's described in gdb/doc/LRS.
> Seems reasonable to me.  It does assume that we know the labels for the
> ranges potentially before we actually emit code which can be a problem.

Hmm.  Stabs for locals are emitted after all the function's code, so
those should be okay, right?  So formal parameters are the real
problem, since their stabs are emitted at the top of the function.

However, GCC emits two stabs for each parameter --- one for the
DECL_INCOMING_RTL, and then one for the real RTL.  (This is the "two
stabs for one argument" behavior we discussed before.)  And the latter
is emitted at the end of the function.  So if emit the LRS info after
the latter, interior stab (which is the one GDB uses for finding the
variable's value anyway, except for backtraces, ugh), then you should
already know the labels.
From jimb@cygnus.com Tue Jul 13 13:25:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Richard Henderson <rth@cygnus.com>
Cc: law@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Tue, 13 Jul 1999 13:25:00 -0000
Message-id: <np3dysi9gh.fsf@zwingli.cygnus.com>
References: <400.931648196@upchuck.cygnus.com> <np908ljwht.fsf@zwingli.cygnus.com> <19990712193944.A28644@cygnus.com>
X-SW-Source: 1999-q3/msg00063.html
Content-length: 990

> 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?
From jimb@cygnus.com Tue Jul 13 14:22:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Tue, 13 Jul 1999 14:22:00 -0000
Message-id: <np1zeci6tm.fsf@zwingli.cygnus.com>
References: <9500.931826533@upchuck.cygnus.com>
X-SW-Source: 1999-q3/msg00064.html
Content-length: 882

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.
From law@cygnus.com Tue Jul 13 15:45:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: LRS in STABS 
Date: Tue, 13 Jul 1999 15:45:00 -0000
Message-id: <12472.931905804@upchuck.cygnus.com>
References: <np4sj8i9pp.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00065.html
Content-length: 687

  In message < np4sj8i9pp.fsf@zwingli.cygnus.com >you write:
  > Hmm.  Stabs for locals are emitted after all the function's code, so
  > those should be okay, right?  So formal parameters are the real
  > problem, since their stabs are emitted at the top of the function.
Parameters can appear before or after the function body depending on what
particular port you are using.


  > However, GCC emits two stabs for each parameter --- one for the
  > DECL_INCOMING_RTL, and then one for the real RTL.  (This is the "two
  > stabs for one argument" behavior we discussed before.) 
I'm not sure this is entirely correct.  Particularly for parameters which
are passed in registers.

jeff


^ permalink raw reply	[flat|nested] 16+ messages in thread
    • [parent not found: <9500.931826533@upchuck.cygnus.com>]
    * Re: IA32: printing FP register variables
@ 1999-07-09 14:00 Michael Meissner
  0 siblings, 0 replies; 16+ messages in thread
From: Michael Meissner @ 1999-07-09 14:00 UTC (permalink / raw)
  To: bcombee, jimb; +Cc: egcs, gdb

| 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.
From amylaar@cygnus.co.uk Fri Jul 09 14:02:00 1999
From: Joern Rennecke <amylaar@cygnus.co.uk>
To: jimb@cygnus.com (Jim Blandy)
Cc: amylaar@cygnus.co.uk, law@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 14:02:00 -0000
Message-id: <199907092102.WAA31455@phal.cygnus.co.uk>
References: <np908psfqu.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00035.html
Content-length: 293

> 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.
From jimb@cygnus.com Fri Jul 09 14:06:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Michael Meissner <meissner@cygnus.com>
Cc: Jeffrey A Law <law@cygnus.com>, Ben Combee <bcombee@metrowerks.com>, Jim Blandy <jimb@cygnus.com>, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 14:06:00 -0000
Message-id: <np673tsfcd.fsf@zwingli.cygnus.com>
References: <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> <4220.931496340@upchuck.cygnus.com> <19990709100431.A4568@tiktok.cygnus.com>
X-SW-Source: 1999-q3/msg00036.html
Content-length: 993

> 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.
From jimb@cygnus.com Fri Jul 09 14:13:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Joern Rennecke <amylaar@cygnus.co.uk>
Cc: bcombee@metrowerks.com (Ben Combee), egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 14:13:00 -0000
Message-id: <np4sjdsf19.fsf@zwingli.cygnus.com>
References: <199907091724.SAA31114@phal.cygnus.co.uk>
X-SW-Source: 1999-q3/msg00037.html
Content-length: 378

> 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.
From jimb@cygnus.com Fri Jul 09 14:44:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: "Ben Combee" <bcombee@metrowerks.com>
Cc: <egcs@egcs.cygnus.com>, <gdb@sourceware.cygnus.com>
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 14:44:00 -0000
Message-id: <nplncpqz10.fsf@zwingli.cygnus.com>
References: <199907090356.WAA01337@zwingli.cygnus.com> <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> <np3dyxu2ua.fsf@zwingli.cygnus.com> <014f01beca41$c42b4e50$3404010a@metrowerks.com> <npaet5sg0c.fsf@zwingli.cygnus.com> <01cc01beca4d$f76868a0$3404010a@metrowerks.com>
X-SW-Source: 1999-q3/msg00038.html
Content-length: 372

> 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.
From muller@cerbere.u-strasbg.fr Fri Jul 09 15:03:00 1999
From: muller@cerbere.u-strasbg.fr
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: FP stack empty at function entry? not always
Date: Fri, 09 Jul 1999 15:03:00 -0000
Message-id: <3.0.6.32.19990710000504.0085b490@ics.u-strasbg.fr>
References: <Ben> <Combee"'s> <message> <of> <Fri,> <9> <Jul> <1999> <15:59:41> <-0500> <199907090356.WAA01337@zwingli.cygnus.com> <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> <np3dyxu2ua.fsf@zwingli.cygnus.com> <014f01beca41$c42b4e50$3404010a@metrowerks.com> <npaet5sg0c.fsf@zwingli.cygnus.com> <01cc01beca4d$f76868a0$3404010a@metrowerks.com> <nplncpqz10.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00039.html
Content-length: 1663

At 16:44 09/07/99 -0500, you wrote:
>
>
>> 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.

 Sorry to disappoint you, but I know of at least one compiler
that breaks this rule : Free Pascal Compiler !
 If you call a real function within a math operation 
you are not garanteed that the stack is empty at entry !
This is risky in the sense that you can get stack overflow, but
it generates faster code!
At compile time, there is a check of FPU stack overflow, 
but its only partial (especially it can not be
perfect for functions calling themselves or
with function variables)

 I am currently converting the extension of GDB to pascal language
to version 4.18 and I would like to insert this in the official GDB
sources, but I don't know to whom I should send the diffs for this!

 I am member of the development team of FPC (free pascal compiler)
and I sent my patches (relative to v4.17 to the GPC maintainers
but never really got feedback!) This is annoying because my patches have
some small parts which are compiler specific and I don't know really how to
cope with this!

 Another question is relative to STABS format,
I would like to know if this format is still subject to improovements or if
it 
is totally freezed specifications
(especially object extensions and
what I found mostly missing in STABS : browser information!)


^ permalink raw reply	[flat|nested] 16+ messages in thread
    [parent not found: <199907091724.SAA31114@phal.cygnus.co.uk>]
    * IA32: printing FP register variables
@ 1999-07-08 20:56 Jim Blandy
  1999-07-08 22:12 ` Jeffrey A Law
       [not found] ` <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com>
  0 siblings, 2 replies; 16+ messages in thread
From: Jim Blandy @ 1999-07-08 20:56 UTC (permalink / raw)
  To: egcs, gdb

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.
From bcombee@metrowerks.com Thu Jul 08 21:18:00 1999
From: "Ben Combee" <bcombee@metrowerks.com>
To: "Jim Blandy" <jimb@cygnus.com>, <egcs@egcs.cygnus.com>, <gdb@sourceware.cygnus.com>
Subject: Re: IA32: printing FP register variables
Date: Thu, 08 Jul 1999 21:18:00 -0000
Message-id: <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com>
References: <199907090356.WAA01337@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00019.html
Content-length: 2585

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


^ permalink raw reply	[flat|nested] 16+ messages in thread
    end of thread, other threads:[~1999-07-26 13:15 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <400.931648196@upchuck.cygnus.com>
     [not found] ` <np908ljwht.fsf@zwingli.cygnus.com>
     [not found]   ` <9209.931822541@upchuck.cygnus.com>
1999-07-12 16:50     ` IA32: printing FP register variables Joern Rennecke
1999-07-12 17:18     ` Robert Lipe
1999-07-12 19:40   ` Richard Henderson
     [not found]     ` <np3dysi9gh.fsf@zwingli.cygnus.com>
1999-07-13 16:05       ` Richard Henderson
     [not found] <9500.931826533@upchuck.cygnus.com>
     [not found] ` <np1zeci6tm.fsf@zwingli.cygnus.com>
     [not found]   ` <npn1ws2xp1.fsf@zwingli.cygnus.com>
1999-07-19 23:41     ` Richard Henderson
1999-07-26 11:43       ` Jim Blandy
1999-07-26 13:15         ` Richard Henderson
1999-07-09 14:00 Michael Meissner
     [not found] <199907091724.SAA31114@phal.cygnus.co.uk>
     [not found] ` <00d401beca31$3d752c10$3404010a@metrowerks.com>
1999-07-09 10:52   ` Jeffrey A Law
1999-07-09 13:50   ` Jim Blandy
  -- strict thread matches above, loose matches on Subject: below --
1999-07-08 20:56 Jim Blandy
1999-07-08 22:12 ` Jeffrey A Law
     [not found] ` <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com>
1999-07-08 22:04   ` Jeffrey A Law
1999-07-09  7:04     ` Michael Meissner
1999-07-10 11:00       ` Tom Tromey
1999-07-09 10:53   ` Jim Blandy

    This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox