IA32: printing FP register variables

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

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

[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
From amylaar@cygnus.co.uk Fri Jul 09 10:31:00 1999
From: Joern Rennecke <amylaar@cygnus.co.uk>
To: bcombee@metrowerks.com (Ben Combee)
Cc: jimb@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 10:31:00 -0000
Message-id: <199907091724.SAA31114@phal.cygnus.co.uk>
References: <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com>
X-SW-Source: 1999-q3/msg00023.html
Content-length: 520

> I would suggest that we may use a "negative" ST value.  The debugger can
> always know the depth of the stack from reading the status registers, so
> saying that something was in ST(7) could be interpreted as the top-most
> stack item, ST(6) as one below that, and so on.  As long as the relative
> position of items on the stack didn't change (this var is always 2 from the
> top), this should be OK.

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

> > I would suggest that we may use a "negative" ST value.  The debugger can
> > always know the depth of the stack from reading the status registers, so
> > saying that something was in ST(7) could be interpreted as the top-most
> > stack item, ST(6) as one below that, and so on.  As long as the relative
> > position of items on the stack didn't change (this var is always 2 from
the
> > top), this should be OK.
>
> I think you get more stable position designations by considering the
> position relative to the bottom of the stack.

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

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

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

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

Re: IA32: printing FP register variables

[Tom Tromey]

>>>>> "Michael" == Michael Meissner <meissner@cygnus.com> writes:

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

FWIW this is the also sort of information you need to build tables for
a precise garbage collector.  A precise GC needs to know when a
pointer (even a disguised one) has been loaded into a register, or
spilled to the stack.

Tom
From malachai@iname.com Sat Jul 10 14:36:00 1999
From: Shawn Halpenny <malachai@iname.com>
To: gdb@sourceware.cygnus.com
Subject: XCOFF support
Date: Sat, 10 Jul 1999 14:36:00 -0000
Message-id: <19990710173405.A23094@cs163.humb.nt.com>
X-SW-Source: 1999-q3/msg00043.html
Content-length: 1133

Since a preliminary search of the mail archives hasn't turned up anything
conclusive, I was wondering if anyone has done any work with XCOFF (I'm
using xlC 3.1.4 on an AIX 4.2.1 box) to _fully_ support the .stabx symbol
table entries.  If someone has patches or at least some work in that area
I'd be interested in hearing from you.  Failing that, some direction on
where I should start to add this sort of thing will do.  Best of all, of
course, would be to be told that "gdb 4.18 (which I'm using) supports that
already and you just didn't build it correctly".  Specifically, my problem
is that all of my attempts to read class/struct data in a C++ object file
all come back with "<unknown type>".  

For the curious, XCOFF is fully described at
http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/files/aixfiles/XCOFF.htm

-- 
Shawn Halpenny |        Maniacal@I Ache, Ohm    |  "Universal Danger!"
               +- - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - \
               | vi:G3kfM~lxfAPXh~l~2x2FirllpfcxlrifaprmfOX~Xp2hr.lrcelyl2p
- - - - - - - -|    fU~X~refsPprnlxppri2lxlpr,pFrpprrfaPlpfiprgllxp~3Xlp3l4x
From law@cygnus.com Sat Jul 10 20:07:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: "Ben Combee" <bcombee@metrowerks.com>, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables 
Date: Sat, 10 Jul 1999 20:07:00 -0000
Message-id: <546.931649446@upchuck.cygnus.com>
References: <np3dyxu2ua.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00045.html
Content-length: 716

  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
From law@cygnus.com Sat Jul 10 20:07:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: "Ben Combee" <bcombee@metrowerks.com>, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables 
Date: Sat, 10 Jul 1999 20:07:00 -0000
Message-id: <430.931648506@upchuck.cygnus.com>
References: <npbtdlsg2i.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00044.html
Content-length: 570

  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
From law@cygnus.com Sat Jul 10 20:08:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Joern Rennecke <amylaar@cygnus.co.uk>, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables 
Date: Sat, 10 Jul 1999 20:08:00 -0000
Message-id: <400.931648196@upchuck.cygnus.com>
References: <np908psfqu.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00046.html
Content-length: 975

  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
From law@cygnus.com Sat Jul 10 20:09:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Michael Meissner <meissner@cygnus.com>, Ben Combee <bcombee@metrowerks.com>, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables 
Date: Sat, 10 Jul 1999 20:09:00 -0000
Message-id: <383.931648016@upchuck.cygnus.com>
References: <np673tsfcd.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00047.html
Content-length: 2146

  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
From jtc@redback.com Mon Jul 12 10:54:00 1999
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: IA32 FP
Date: Mon, 12 Jul 1999 10:54:00 -0000
Message-id: <5m3dyt3gbw.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00048.html
Content-length: 968

I haven't jumped in on running thread on IA32 FP until now.

Although most of the IA32 systems in common use today support FP, only
a handful have FP support in GDB.  IMO, one of the reasons for this is
that the base header, tm-i386.h, has little support for FP registers
(NUM_FREGS is 0, no REGISTER_CONVERT_TO_{RAW,VIRTUAL} macros, etc.

This may be a good opportunity to address this.  At the possible
expense of some of the older targets that really don't have any FP
support, the target headers for more today's popular systems (*BSD,
GNU/Linux, GNU/Hurd, cygwin, embedded, etc.) would be greatly
simplified.  Plus any breakage would be quite obvious and easy to 
fix when someone attempts to build those configs.

We could try to build cross debuggers for all the IA32 targets, but we
might not be successful.  I've encountered problems in the past where 
target headers require native headers, etc. and fail to build.

	--jtc

-- 
J.T. Conklin
RedBack Networks
From jimb@cygnus.com Mon Jul 12 12:29:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Andi Kleen <ak@muc.de>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Linux changes for GDB
Date: Mon, 12 Jul 1999 12:29:00 -0000
Message-id: <npg12tk6q8.fsf@zwingli.cygnus.com>
References: <199907090232.VAA01308@zwingli.cygnus.com> <k2iu7sskdw.fsf@zero.aec.at>
X-SW-Source: 1999-q3/msg00049.html
Content-length: 751

> > Then there are some bug fixes:
> > - GDB can step into functions in shared libraries correctly.  On
> >   Redhat 5.2, at least, you sometimes end up in `strcmp'.  (I need to
> >   write a test for this one.)
> 
> The main problem on RH5.2 and RH6 seems to be that libc is not
> stripped

You know, there do exist shared libraries other than libc.  And some
people even have to debug them!  :)  I don't think stripping shared
libraries is really the way to resolve this problem.


> so once you enter a libc function by mistake with 's' you get hundreds
> of error messages because of the missing source file. Is there a elegant
> fix for that? (e.g. some way to specify to gdb to never look for some
> sources)

No, I don't have any fix for that.
From jimb@cygnus.com Mon Jul 12 12:44:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: IA32 FP
Date: Mon, 12 Jul 1999 12:44:00 -0000
Message-id: <npemidk61m.fsf@zwingli.cygnus.com>
References: <5m3dyt3gbw.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00050.html
Content-length: 546

> Although most of the IA32 systems in common use today support FP,
> only a handful have FP support in GDB.  [...]  This may be a good
> opportunity to address this.

That's exactly what I'm trying to do.  My immediate interest is making
Linux work, but if we IA32 maintainers talk about it a bit, we can all
use the same solution.

There's a lot of gratuitous duplication among the gdb/config/i386
headers.  (For fun, diff nm-i386v.h and nm-i386sco.h.)  So I don't think
there's any technical reason we couldn't do a great deal of
unification.
From jimb@cygnus.com Mon Jul 12 15:50:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: law@cygnus.com
Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: LRS in STABS
Date: Mon, 12 Jul 1999 15:50:00 -0000
Message-id: <npaet1jxf7.fsf@zwingli.cygnus.com>
References: <383.931648016@upchuck.cygnus.com>
X-SW-Source: 1999-q3/msg00051.html
Content-length: 2134

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

Tired of doing the merge every month?  :)

Is there a reason not to merge what we have now into EGCS, aside from
its quirkiness?  It seems to me like it carries the right information.

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.

The drawbacks are:
1) We're inventing a new notation.  But if EGCS doesn't like the
   existing LRS notation, I guess it's inevitable.
2) We avoid putting cruft in EGCS, but GDB acquires new complexity,
   because it needs to understand both notations, for at least a
   while.  Maybe this isn't necessary, since only GnuPRO GCC produces
   it, and if someone gets a new GDB, they'll also get a new GCC.
3) We're investing effort in what I thought was a dead notation.  We
   should be implementing Dwarf2 compression in the linker and
   encouraging people to switch, not adding more garbage to STABS.
From jimb@cygnus.com Mon Jul 12 16:09:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: law@cygnus.com
Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Mon, 12 Jul 1999 16:09:00 -0000
Message-id: <np908ljwht.fsf@zwingli.cygnus.com>
References: <400.931648196@upchuck.cygnus.com>
X-SW-Source: 1999-q3/msg00052.html
Content-length: 603

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.
From law@cygnus.com Mon Jul 12 16:23: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: Mon, 12 Jul 1999 16:23:00 -0000
Message-id: <9101.931821781@upchuck.cygnus.com>
References: <npaet1jxf7.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00053.html
Content-length: 3547

  In message < npaet1jxf7.fsf@zwingli.cygnus.com >you write:
  > > 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.
  > 
  > Tired of doing the merge every month?  :)
It's not so much the merge issues as a desire to get the code available to
more folks.  It's doing neither Cygnus nor egcs any good sitting in just
the Cygnus sources.  Both groups benefit from wider distribution of that code.

  > Is there a reason not to merge what we have now into EGCS, aside from
  > its quirkiness?  It seems to me like it carries the right information.
It certainly needs some cleanup.  The way we find suitable loops for LRS
needs to be using the cfg and code to detect natural loops.  I'm not real
happy with some of the stuff in final & dbxout.

Looking further out, David Miller has been working on a new register allocator
which would do LRS internally, which would make much of the stuff Cygnus did
obsolete (LRS is better handled by building interference graphs during 
allocation and splitting in response to register pressure).

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


  > The drawbacks are:
  > 1) We're inventing a new notation.  But if EGCS doesn't like the
  >    existing LRS notation, I guess it's inevitable.
I wouldn't go quite that far.  How about "I think we can do better" :-)

  > 2) We avoid putting cruft in EGCS, but GDB acquires new complexity,
  >    because it needs to understand both notations, for at least a
  >    while.  Maybe this isn't necessary, since only GnuPRO GCC produces
  >    it, and if someone gets a new GDB, they'll also get a new GCC.
They would get both in lock step.  It would mean objects compiled with
older GnuPro compilers could not be debugged with a newer gdb if they had
any live range splits.  But this is really a Cygnus issue and shouldn't
effect what we do for gdb & gcc.  If it means Cygnus has to keep some
compat code in gdb for a while, we can do that.

  > 3) We're investing effort in what I thought was a dead notation.  We
  >    should be implementing Dwarf2 compression in the linker and
  >    encouraging people to switch, not adding more garbage to STABS.
Yup.  This is one of the biggest reasons to live with the existing stabs
notation and instead spend our time working on getting the dwarf2 range stuff
working which is going to require both gcc & gdb work.

jeff

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.
From jimb@cygnus.com Fri Jul 09 11:14:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: law@cygnus.com
Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 11:14:00 -0000
Message-id: <np1zehu1vd.fsf@zwingli.cygnus.com>
References: <4264.931496789@upchuck.cygnus.com>
X-SW-Source: 1999-q3/msg00027.html
Content-length: 1208

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

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

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

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

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

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

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

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

I guess an example would help...

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

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

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

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

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'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.
From jimb@cygnus.com Fri Jul 09 13:52: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 13:52:00 -0000
Message-id: <npaet5sg0c.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>
X-SW-Source: 1999-q3/msg00031.html
Content-length: 384

> 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?
From jimb@cygnus.com Fri Jul 09 13:57:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Joern Rennecke <amylaar@cygnus.co.uk>
Cc: law@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 13:57:00 -0000
Message-id: <np908psfqu.fsf@zwingli.cygnus.com>
References: <199907091822.TAA31184@phal.cygnus.co.uk>
X-SW-Source: 1999-q3/msg00032.html
Content-length: 853

> > 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.
From bcombee@metrowerks.com Fri Jul 09 14:00:00 1999
From: "Ben Combee" <bcombee@metrowerks.com>
To: "Jim Blandy" <jimb@cygnus.com>
Cc: <egcs@egcs.cygnus.com>, <gdb@sourceware.cygnus.com>
Subject: Re: IA32: printing FP register variables
Date: Fri, 09 Jul 1999 14:00:00 -0000
Message-id: <01cc01beca4d$f76868a0$3404010a@metrowerks.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>
X-SW-Source: 1999-q3/msg00033.html
Content-length: 999

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

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

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.
From law@cygnus.com Mon Jul 12 17:07:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Joern Rennecke <amylaar@cygnus.co.uk>
Cc: jimb@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables 
Date: Mon, 12 Jul 1999 17:07:00 -0000
Message-id: <9384.931824345@upchuck.cygnus.com>
References: <199907122349.AAA25740@phal.cygnus.co.uk>
X-SW-Source: 1999-q3/msg00057.html
Content-length: 766

  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

[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
From amylaar@cygnus.co.uk Mon Jul 12 17:24:00 1999
From: Joern Rennecke <amylaar@cygnus.co.uk>
To: law@cygnus.com
Cc: amylaar@cygnus.co.uk, jimb@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Mon, 12 Jul 1999 17:24:00 -0000
Message-id: <199907130023.BAA25804@phal.cygnus.co.uk>
References: <9384.931824345@upchuck.cygnus.com>
X-SW-Source: 1999-q3/msg00059.html
Content-length: 1137

> 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.
From law@cygnus.com Mon Jul 12 17:49:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Robert Lipe <robertlipe@usa.net>
Cc: Jim Blandy <jimb@cygnus.com>, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables 
Date: Mon, 12 Jul 1999 17:49:00 -0000
Message-id: <9500.931826533@upchuck.cygnus.com>
References: <19990712191723.E3871@rjlhome.sco.com>
X-SW-Source: 1999-q3/msg00060.html
Content-length: 1045

  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

[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~
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

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~
From jimb@cygnus.com Wed Jul 14 17:06:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: gdb@sourceware.cygnus.com, DJ Delorie <dj@delorie.com>
Subject: Re: Single-stepping through INT nn instructions
Date: Wed, 14 Jul 1999 17:06:00 -0000
Message-id: <np7lo2hkam.fsf@zwingli.cygnus.com>
References: <199907140747.DAA03375@indy.delorie.com>
X-SW-Source: 1999-q3/msg00067.html
Content-length: 1023

> I'm not sure if this is the right forum to discuss the above; if not,
> please tell me where to post.

I think this is best for gdb@sourceware.cygnus.com.  I've changed the
CC'd address.

> The INT nn and INTO instructions reset the trace bit on x86.  So if
> you are single-stepping through a function that issues these
> instructions, the single-step mode is effectively turned off when you
> step over one of them.

So you're trying to step *into* an int, not over it, right?  It seems
to me that the TF flag ought to work for stepping over an int.

The pentium manual says:

    The INT instructions, however, do clear the TF flag.  Therefore,
    software debuggers which single-step code must recognize and
    emulate INT n or INTO instructions rather than executing them
    directly.

You might look into defining SOFTWARE_SINGLE_STEP for i386; it could
check the next instruction, emulate INT n and INTO, and use the TF
flag for all others.

Are you sure the other platforms can do this?  I bet they just punt.
From eliz@delorie.com Thu Jul 15 02:14:00 1999
From: Eli Zaretskii <eliz@delorie.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sourceware.cygnus.com, DJ Delorie <dj@delorie.com>
Subject: Re: Single-stepping through INT nn instructions
Date: Thu, 15 Jul 1999 02:14:00 -0000
Message-id: <199907150913.FAA01508@indy.delorie.com>
X-SW-Source: 1999-q3/msg00068.html
Content-length: 482

> So you're trying to step *into* an int, not over it, right?

I meant this: suppose the debuggee is stopped right in front of the
INT nn instruction.  Now I want to do a "stepi" in GDB.

> You might look into defining SOFTWARE_SINGLE_STEP for i386

Thanks, I will look it up.

> Are you sure the other platforms can do this?  I bet they just punt.

Well, I usually don't dare to assume that DJGPP solves problems that
other platforms punt ;-).  At least not without sound reasons.
From rogerc@ignitus.com Thu Jul 15 07:51:00 1999
From: Roger Cruz <rogerc@ignitus.com>
To: gdb@sourceware.cygnus.com
Subject: Can't build GDB 4.18 under Cygnus 2.0.1
Date: Thu, 15 Jul 1999 07:51:00 -0000
Message-id: <378DF57E.3D26CA78@ignitus.com>
X-SW-Source: 1999-q3/msg00069.html
Content-length: 779

I have CygWin installed in my WinNT 40 PC.  I downloaded GDB 4.18, unzipped
and untar'ed it and ./configure it without specifying a target or host.  It
correctly configured it for i686-pc-cygwin.  I then proceeded to run "make"
at the top level and it complained that there were no targets to be made.
Looking at the makefile created, I see that this is also true.  Why does
the make file failed to be created with any targets?  The only problem I
saw during the configuration was a warning about an unterminated sed "s"
command.  I couldn't track which sed cmd this was.

Can any one please help?

Thanks
Roger

PS: Please email me directly as I do not subscribe to this list.  Also,
note that you must first remove "_nojunk" from the email address:
rogerc_nojunk@ignitus.com

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~
From tm@netcom.com Tue Jul 20 12:14:00 1999
From: Toshiyasu Morita <tm@netcom.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB with Hitachi Linker output?
Date: Tue, 20 Jul 1999 12:14:00 -0000
Message-id: <199907201913.MAA22621@netcom13.netcom.com>
References: <5mwvvw74ic.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00095.html
Content-length: 1478

The SRCONV utility is actually pretty broken, through no fault of Cygnus.

We ran into the problem three years ago that SRCONV-emitted files caused the 
Hitachi in-circuit emulator to crash. After much consultation with both 
sides, we determined that:

1) The Hitachi SYSROF spec only describes the output of the data from the 
compiler/linker, and do not specify implicit ordering dependencies, and 

2) linker/debugger are fragile and do not emit  proper error messages 
when a certain section is out of order.

Therefore, it was impossible to debug the problem and we gave up on SRCONV.

Toshi



> 
> >>>>> "Bill" == Bill Gatliff <gatliff@haulpak.com> writes:
> Bill> Is anyone using GDB sh-hitachi-hms with executables supplied by
> Bill> the Hitachi linker?
> 
> I don't think so.  
> 
> AFAIK, the hitachi object format is sysroff.  There is a sysroff to
> COFF converter in binutils (srconv), but nothing to do the reverse.  I
> vaguely remember a receiving email from Ian Taylor two or three years
> ago that said that support for whatever was missing in BFD that caused
> srconv to be a separate program (instead of available through objcopy)
> had been added.  That project never became high enough priority to
> follow up.  
> 
> It's possible that the email was referring to nlmconv instead of
> srconv, since I worked on both programs in that time frame.  I'm 
> sorry I can't remember any more details.
> 
> 	--jtc
> 
> -- 
> J.T. Conklin
> RedBack Networks
> 

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.
From jimb@cygnus.com Mon Jul 26 11:55:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Neal Cardwell <cardwell@cs.washington.edu>
Cc: gdb@sourceware.cygnus.com
Subject: Re: signals at breakpoints in Linux
Date: Mon, 26 Jul 1999 11:55:00 -0000
Message-id: <npbtcz44xd.fsf@zwingli.cygnus.com>
References: <Pine.LNX.4.10.9907240149141.3002-100000@saba.cs.washington.edu>
X-SW-Source: 1999-q3/msg00099.html
Content-length: 979

> I'm trying to build a minimal debugger under Linux that maintains a set of
> breakpoints and prints out some information each time a breakpoint is hit.
> It works fine, except for the case where the child process executes a
> breakpoint instruction and wait(2) tells me that a (non-SIGTRAP) signal is
> pending. I can't seem to handle this case correctly, no matter what i try.
> What is the correct course of action when a breakpoint and signal are
> encountered simultaneously? I've tried looking at the sources for GDB, but
> they're pretty tough to wade through.

I'm not positive about this, but I think you're misunderstanding the
results from ptrace.  Not that they're wonderfully clear to begin
with.

The result from wait tells you why the program stopped.  As I
understand it, it either stopped because of a breakpoint, or it
stopped because of a signal --- it can't stop for both reasons.

What exactly is wait returning?  Where exactly is the PC when wait
returns?
From rogerc@ignitus.com Mon Jul 26 13:01:00 1999
From: Roger Cruz <rogerc@ignitus.com>
To: gdb@sourceware.cygnus.com
Subject: How do I type cast an array of strings in GDB?
Date: Mon, 26 Jul 1999 13:01:00 -0000
Message-id: <379CBFBC.6164B1CA@ignitus.com>
X-SW-Source: 1999-q3/msg00100.html
Content-length: 1158

I have the following definition in a file, compiled without the -g switch:

LOCAL char *  semTypeMsg [MAX_SEM_TYPE] =
    {
    "BINARY", "MUTEX", "COUNTING", "OLD", "\0", "\0", "\0", "\0"
    };

I want to index this array to get to the different strings:

(gdb) p semTypeMsg[0]
cannot subscript something of type `<data variable, no debug info>'
(gdb) whatis semTypeMsg
type = <data variable, no debug info>

But because it was compiled without the -g switch, I can't do this
directly.  How do I cast this variable name to allow me access to the
strings?  I've tried a bunch of compinations and they are all unsuccessful

(gdb) p ((char *)semTypeMsg)
$19 = 0xfdd8c "BINARY"
(gdb) p ((char *)semTypeMsg)[0]
$20 = 66 'B'
(gdb) p ((char **)semTypeMsg)[0]
$21 = 0x42494e41Requested target address (0x42494e41) is outside
the valid memory range: 0x0-0x1000000

(gdb) p ((char **)semTypeMsg)+1
$22 = (char **) 0xfdd90
(gdb) p *(((char **)semTypeMsg)+1)
$23 = 0x52590000Requested target address (0x52590000) is outside
the valid memory range: 0x0-0x1000000

(gdb) p (char *)(((char **)semTypeMsg)+1)
$24 = 0xfdd90 "RY"
(gdb) p (char *)(((char **)semTypeMsg)+1)

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~
From jimb@cygnus.com Mon Jul 26 18:50:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Sekaran Nanja <snanja@cup.hp.com>
Cc: Rajiv Mirani <mirani@cup.hp.com>, Mike Vermeulen <mev@hpclhayb.cup.hp.com>, gdb@sourceware.cygnus.com
Subject: Re: Regarding Range Table
Date: Mon, 26 Jul 1999 18:50:00 -0000
Message-id: <npn1wi3m05.fsf@zwingli.cygnus.com>
References: <37990D39.B393D61B@cup.hp.com> <np908343yh.fsf@zwingli.cygnus.com> <379CCBBD.6E3FC2F3@cup.hp.com>
X-SW-Source: 1999-q3/msg00102.html
Content-length: 6697

[To gdb@sourceware readers: Sekaran is working on helping GDB debug
optimized code.  He would like to extend the way GDB represents
variables that live in different places at different times --- for
example, a variable that mostly lives on the stack, except in the body
of a particular loop, where it is brought into a register.

GDB represents such variables using multiple struct symbol objects,
one for each home the variable occupies.  The `ranges' element of the
`struct symbol' lists the addresses at which that `struct symbol' is
appropriate.

This is a weird representation, since you can have several struct
symbol objects corresponding to a single variable.  It would be more
intuitive to identify each variable with a single `struct symbol'
object, and have that object carry a mapping from code addresses to
homes.  But here we are.]



Sekaran Nanja <snanja@cup.hp.com> writes:
 
Jim> Would it be okay if we had this discussion on gdb@sourceware.cygnus.com?

Sekaran> I think it is OK.

Jim> It's fine with me to extend the range_list struct, as long as the new
Jim> semantics are very clear.  If they're not well-explained, or they're
Jim> muddy, then we won't be able to maintain it.
Jim>
Jim> So I need to understand exactly what you want to do to symbols and
Jim> their range lists, and how to interpret the resulting structures.

Sekaran> Please note that HP captures the following information for live
Sekaran> ranges of variables: Symbol Address (Register - but this can
Sekaran> possibly change for different code ranges)

Jim> This is just a mapping from code addresses onto variable homes, right?
Jim> To represent this information, no changes to GDB's symbol structures
Jim> are necessary, right?

Sekaran> We don't need to change the symbol struct but we need to
Sekaran> change range_list struct to support this.  Please note that
Sekaran> Register value for the assigned symbol may change in code
Sekaran> ranges and so we need to keep the address info. in
Sekaran> range_list. I am planning to change the struct range_list as
Sekaran> follows:
Sekaran> 
Sekaran> struct range_list {
Sekaran>          unsigned int  set_early : 1;
Sekaran>          unsigned int set_late : 1;
Sekaran>          unsigned int unknown : 1;
Sekaran>          unsigned int reserved  : 29
Sekaran> 
Sekaran>         enum  address_class  aclass BYTE_BITFIELD;
Sekaran>         CORE_ADDR   symbol_address;
Sekaran>          int  comes_from_line;
Sekaran>          int  moved_to_line;
Sekaran> 
Sekaran>         CORE_ADDR  start;
Sekaran>         CORE_ADDR  end;
Sekaran>          struct range_list  *next;
Sekaran> }

Sekaran> Set Early/ Set Late - Flag for critical point assignment (To provide
Sekaran> useful warning to the user) and possibly associated line numbers for
Sekaran> these.
 
Jim> I don't understand what this is.  Could you explain it in more
Jim> detail?

Sekaran> Please note that due to optimization, critical assignment
Sekaran> statement(s) can possibly moved around.  In these cases, the
Sekaran> user needs to be warned regarding this optimization by
Sekaran> displaying warning to the user that either the assignment has
Sekaran> taken place earlier at a specific line or it is going to
Sekaran> happen at a specific line.  Please note that the following
Sekaran> newly added fields to range_list are used support this
Sekaran> feature:
Sekaran>
Sekaran> set_early
Sekaran> set_late
Sekaran> comes_from_line
Sekaran> moved_to_line.


I am still not clear on what set_early, set_late, comes_from_line and
moved_to_line would mean, but I am guessing that they are meant to
handle cases like these:

- a variable which is live in the source code at a given point is not
  actually live in the optimized code which the user is debugging,
  because the compiler has moved an assignment to the variable from
  before the current source line to after the current source line.

- a variable is live in the source code at a given point, but all its
  uses have been moved above it, along with *another* assignment to
  the variable.  So the variable is live, but its value isn't going to
  go where you'd expect.

(Here, "before" and "after" refer to control flow, not to source
positions).

Is that correct?

GDB's representation for split live ranges is not very intuitive, and
I don't think you're using it correctly.

GDB uses a separate struct symbol for each home a variable might have.
A struct symbol's `ranges' list lists those address ranges over which
the variable home given in that struct symbol applies.

So, for example, if a variable `foo' usually lives on the stack, but
lives in register 5 from code addresses 0x1020 and 0x1030, and
register 6 from code addresses 0x1040 to 0x1050, then you would have:

- the primary struct symbol, whose aclass is LOC_LOCAL, and whose
  SYMBOL_VALUE is the offset from the frame base, whose `ranges' list
  is empty, and whose `aliases' list contains two struct symbols:

  - the first alias symbol, whose aclass is LOC_REGISTER and whose
    SYMBOL_VALUE is 5, and whose `ranges' list contains the single
    element, {start=0x1020, end=0x1030, next=0}

  - the second alias symbol, whose aclass is LOC_REGISTER and whose
    SYMBOL_VALUE is 6, and whose `ranges' list contains the single
    element, {start=0x1040, end=0x1050, next=0}.

All of these struct symbols have the name `foo', and all refer to the
same variable.  (I think this is crummy, but that's the way it is.)

In other words, when a variable has several homes, GDB doesn't
represent this using a single struct symbol with several elements in
its `ranges' list, each one specifying a particular home for that
range.  Instead, GDB represents this using multiple `struct symbol'
objects, each of which probably has a single element in its `ranges'
list.

The only case where a symbol's `ranges' list would have more than one
element is if the variable has the same home in several distinct
ranges.

An OP_VAR_VALUE node of a GDB `struct expression' will contain a
reference to the symbol object appropriate for the location at which
the expression will be evaluated --- it could be a the primary or an
alias.  The expression evaluator assumes that the home in the struct
symbol is correct.

So instead of adding `aclass' and `symbol_address' to struct
range_list, it seems to me that you should instead build a separate
struct symbol for each home the variable might have.

It makes more sense to me to add your new info to the struct symbol
itself, so that value_of_variable can check it and complain
appropriately.  It would be nice to do it in a way which doesn't use
much space if we don't have this kind of information for the symbol.

What do you think?
From jimb@cygnus.com Mon Jul 26 19:09:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Richard Henderson <rth@cygnus.com>
Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Mon, 26 Jul 1999 19:09:00 -0000
Message-id: <nphfmq3ktz.fsf@zwingli.cygnus.com>
References: <9500.931826533@upchuck.cygnus.com> <np1zeci6tm.fsf@zwingli.cygnus.com> <npn1ws2xp1.fsf@zwingli.cygnus.com> <19990719234100.C17063@cygnus.com> <npemhv45i6.fsf@zwingli.cygnus.com> <19990726131518.D2954@cygnus.com>
X-SW-Source: 1999-q3/msg00103.html
Content-length: 179

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.
From jimb@cygnus.com Mon Jul 26 19:12:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Richard Henderson <rth@cygnus.com>
Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: IA32: printing FP register variables
Date: Mon, 26 Jul 1999 19:12:00 -0000
Message-id: <npg12a3kom.fsf@zwingli.cygnus.com>
References: <9500.931826533@upchuck.cygnus.com> <np1zeci6tm.fsf@zwingli.cygnus.com> <npn1ws2xp1.fsf@zwingli.cygnus.com> <19990719234100.C17063@cygnus.com> <npemhv45i6.fsf@zwingli.cygnus.com> <19990726131518.D2954@cygnus.com>
X-SW-Source: 1999-q3/msg00104.html
Content-length: 322

> > 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'.
From jimb@cygnus.com Mon Jul 26 19:15:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Roger Cruz <rogerc@ignitus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: How do I type cast an array of strings in GDB?
Date: Mon, 26 Jul 1999 19:15:00 -0000
Message-id: <npemhu3kk4.fsf@zwingli.cygnus.com>
References: <379CBFBC.6164B1CA@ignitus.com>
X-SW-Source: 1999-q3/msg00105.html
Content-length: 164

From an operational perspective, you want to prevent GDB from fetching
the value of semTypeMsg as a machine word.  You might try:

print ((char **) &semTypeMsg)[1]
From snanja@cup.hp.com Mon Jul 26 19:36:00 1999
From: Sekaran Nanja <snanja@cup.hp.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Rajiv Mirani <mirani@cup.hp.com>, Mike Vermeulen <mev@hpclhayb.cup.hp.com>, gdb@sourceware.cygnus.com
Subject: Re: Regarding Range Table
Date: Mon, 26 Jul 1999 19:36:00 -0000
Message-id: <379D1B3A.32B9121B@cup.hp.com>
References: <37990D39.B393D61B@cup.hp.com> <np908343yh.fsf@zwingli.cygnus.com> <379CCBBD.6E3FC2F3@cup.hp.com> <npn1wi3m05.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00106.html
Content-length: 8692

Jim>I am still not clear on what set_early, set_late, comes_from_line and
Jim>moved_to_line would mean, but I am guessing that they are meant to
Jim>handle cases like these:

Jim>- a variable which is live in the source code at a given point is not
Jim>actually live in the optimized code which the user is debugging,
Jim>  because the compiler has moved an assignment to the variable from
Jim> before the current source line to after the current source line.

Jim>- a variable is live in the source code at a given point, but all its
Jim>  uses have been moved above it, along with *another* assignment to
Jim> the variable.  So the variable is live, but its value isn't going to
Jim> go where you'd expect.

Jim>(Here, "before" and "after" refer to control flow, not to source
Jim>positions).

Jim>Is that correct?
Yes. This is correct.

Jim>So instead of adding `aclass' and `symbol_address' to struct
Jim>range_list, it seems to me that you should instead build a separate
Jim>struct symbol for each home the variable might have.

Yes. I agree.


Jim>It makes more sense to me to add your new info to the struct symbol
Jim>itself, so that value_of_variable can check it and complain
Jim>appropriately.  It would be nice to do it in a way which doesn't use
Jim>much space if we don't have this kind of information for the symbol.

Jim>What do you think?
Yes. It makes sense to add this info. to struct symbol to keep things clean but
we lose the new info. for  an alias symbol containing multiple ranges (Ex:
variable has the same home in several distinct ranges.). I think it is better to
save these new info. in  range_list struct. Please let me know what do you think
about this.

Thanks,
Sekaran.

Jim Blandy wrote:

> [To gdb@sourceware readers: Sekaran is working on helping GDB debug
> optimized code.  He would like to extend the way GDB represents
> variables that live in different places at different times --- for
> example, a variable that mostly lives on the stack, except in the body
> of a particular loop, where it is brought into a register.
>
> GDB represents such variables using multiple struct symbol objects,
> one for each home the variable occupies.  The `ranges' element of the
> `struct symbol' lists the addresses at which that `struct symbol' is
> appropriate.
>
> This is a weird representation, since you can have several struct
> symbol objects corresponding to a single variable.  It would be more
> intuitive to identify each variable with a single `struct symbol'
> object, and have that object carry a mapping from code addresses to
> homes.  But here we are.]
>
> Sekaran Nanja <snanja@cup.hp.com> writes:
>
> Jim> Would it be okay if we had this discussion on gdb@sourceware.cygnus.com?
>
> Sekaran> I think it is OK.
>
> Jim> It's fine with me to extend the range_list struct, as long as the new
> Jim> semantics are very clear.  If they're not well-explained, or they're
> Jim> muddy, then we won't be able to maintain it.
> Jim>
> Jim> So I need to understand exactly what you want to do to symbols and
> Jim> their range lists, and how to interpret the resulting structures.
>
> Sekaran> Please note that HP captures the following information for live
> Sekaran> ranges of variables: Symbol Address (Register - but this can
> Sekaran> possibly change for different code ranges)
>
> Jim> This is just a mapping from code addresses onto variable homes, right?
> Jim> To represent this information, no changes to GDB's symbol structures
> Jim> are necessary, right?
>
> Sekaran> We don't need to change the symbol struct but we need to
> Sekaran> change range_list struct to support this.  Please note that
> Sekaran> Register value for the assigned symbol may change in code
> Sekaran> ranges and so we need to keep the address info. in
> Sekaran> range_list. I am planning to change the struct range_list as
> Sekaran> follows:
> Sekaran>
> Sekaran> struct range_list {
> Sekaran>          unsigned int  set_early : 1;
> Sekaran>          unsigned int set_late : 1;
> Sekaran>          unsigned int unknown : 1;
> Sekaran>          unsigned int reserved  : 29
> Sekaran>
> Sekaran>         enum  address_class  aclass BYTE_BITFIELD;
> Sekaran>         CORE_ADDR   symbol_address;
> Sekaran>          int  comes_from_line;
> Sekaran>          int  moved_to_line;
> Sekaran>
> Sekaran>         CORE_ADDR  start;
> Sekaran>         CORE_ADDR  end;
> Sekaran>          struct range_list  *next;
> Sekaran> }
>
> Sekaran> Set Early/ Set Late - Flag for critical point assignment (To provide
> Sekaran> useful warning to the user) and possibly associated line numbers for
> Sekaran> these.
>
> Jim> I don't understand what this is.  Could you explain it in more
> Jim> detail?
>
> Sekaran> Please note that due to optimization, critical assignment
> Sekaran> statement(s) can possibly moved around.  In these cases, the
> Sekaran> user needs to be warned regarding this optimization by
> Sekaran> displaying warning to the user that either the assignment has
> Sekaran> taken place earlier at a specific line or it is going to
> Sekaran> happen at a specific line.  Please note that the following
> Sekaran> newly added fields to range_list are used support this
> Sekaran> feature:
> Sekaran>
> Sekaran> set_early
> Sekaran> set_late
> Sekaran> comes_from_line
> Sekaran> moved_to_line.
>
> I am still not clear on what set_early, set_late, comes_from_line and
> moved_to_line would mean, but I am guessing that they are meant to
> handle cases like these:
>
> - a variable which is live in the source code at a given point is not
>   actually live in the optimized code which the user is debugging,
>   because the compiler has moved an assignment to the variable from
>   before the current source line to after the current source line.
>
> - a variable is live in the source code at a given point, but all its
>   uses have been moved above it, along with *another* assignment to
>   the variable.  So the variable is live, but its value isn't going to
>   go where you'd expect.
>
> (Here, "before" and "after" refer to control flow, not to source
> positions).
>
> Is that correct?
>
> GDB's representation for split live ranges is not very intuitive, and
> I don't think you're using it correctly.
>
> GDB uses a separate struct symbol for each home a variable might have.
> A struct symbol's `ranges' list lists those address ranges over which
> the variable home given in that struct symbol applies.
>
> So, for example, if a variable `foo' usually lives on the stack, but
> lives in register 5 from code addresses 0x1020 and 0x1030, and
> register 6 from code addresses 0x1040 to 0x1050, then you would have:
>
> - the primary struct symbol, whose aclass is LOC_LOCAL, and whose
>   SYMBOL_VALUE is the offset from the frame base, whose `ranges' list
>   is empty, and whose `aliases' list contains two struct symbols:
>
>   - the first alias symbol, whose aclass is LOC_REGISTER and whose
>     SYMBOL_VALUE is 5, and whose `ranges' list contains the single
>     element, {start=0x1020, end=0x1030, next=0}
>
>   - the second alias symbol, whose aclass is LOC_REGISTER and whose
>     SYMBOL_VALUE is 6, and whose `ranges' list contains the single
>     element, {start=0x1040, end=0x1050, next=0}.
>
> All of these struct symbols have the name `foo', and all refer to the
> same variable.  (I think this is crummy, but that's the way it is.)
>
> In other words, when a variable has several homes, GDB doesn't
> represent this using a single struct symbol with several elements in
> its `ranges' list, each one specifying a particular home for that
> range.  Instead, GDB represents this using multiple `struct symbol'
> objects, each of which probably has a single element in its `ranges'
> list.
>
> The only case where a symbol's `ranges' list would have more than one
> element is if the variable has the same home in several distinct
> ranges.
>
> An OP_VAR_VALUE node of a GDB `struct expression' will contain a
> reference to the symbol object appropriate for the location at which
> the expression will be evaluated --- it could be a the primary or an
> alias.  The expression evaluator assumes that the home in the struct
> symbol is correct.
>
> So instead of adding `aclass' and `symbol_address' to struct
> range_list, it seems to me that you should instead build a separate
> struct symbol for each home the variable might have.
>
> It makes more sense to me to add your new info to the struct symbol
> itself, so that value_of_variable can check it and complain
> appropriately.  It would be nice to do it in a way which doesn't use
> much space if we don't have this kind of information for the symbol.
>
> What do you think?