From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Meissner To: Jeffrey A Law Cc: Ben Combee , Jim Blandy , egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Fri, 09 Jul 1999 07:04:00 -0000 Message-id: <19990709100431.A4568@tiktok.cygnus.com> References: <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> <4220.931496340@upchuck.cygnus.com> X-SW-Source: 1999-q3/msg00022.html 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 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" To: , 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.