Re: IA32: printing FP register variables

[Michael Meissner <meissner@cygnus.com>]

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