From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Meissner To: bcombee@metrowerks.com, 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: <199907092100.RAA12783@rtl.cygnus.com> X-SW-Source: 1999-q3/msg00034.html | 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 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: 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 To: Michael Meissner Cc: Jeffrey A Law , Ben Combee , Jim Blandy , 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: 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 To: Joern Rennecke 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: 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 To: "Ben Combee" Cc: , Subject: Re: IA32: printing FP register variables Date: Fri, 09 Jul 1999 14:44:00 -0000 Message-id: References: <199907090356.WAA01337@zwingli.cygnus.com> <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> <014f01beca41$c42b4e50$3404010a@metrowerks.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 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: <9> <1999> <15:59:41> <-0500> <199907090356.WAA01337@zwingli.cygnus.com> <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> <014f01beca41$c42b4e50$3404010a@metrowerks.com> <01cc01beca4d$f76868a0$3404010a@metrowerks.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!)