kushmer@bnlux0.bnl.gov (christopher kushmerick) (01/07/91)
I am having what appears to be recurring and intermittant problems with the integrated debugger. I am trying to use the F-4 (run to cursor) command, and it reports that there is no code generated for this line. Sometimes it works correctly, sometimes not, for the same line. Is anyone else having trouble with f-4? Also, and I invite anyone to disagree: The turbo 6.0 color scheme does not work on a laptop with LCD screen ie there is always something that is invisible. -- Chris Kushmerick kushmer@bnlux0.bnl.gov <===Try this one first kushmerick@pofvax.sunysb.edu
nlarson@isis.cs.du.edu (Neil Larson) (01/10/91)
In article <2394@bnlux0.bnl.gov> kushmer@bnlux0.bnl.gov (christopher kushmerick) writes: >I am having what appears to be recurring and intermittant problems >with the integrated debugger. I am trying to use the F-4 (run to cursor) >command, and it reports that there is no code generated for this line. > >Sometimes it works correctly, sometimes not, for the same line. > Sometimes optimizations made by the compiler consist of using a similar line of code near the one in question instead. Jeesh, this is hard to explain. say you have code that looks like this: calculatecrc16(packet,crcval); if crcval = 0 then crcvalerror := true; calculatecrc16(packet,crcval); the compiler will not create identical machine code for both calls to the procedure calls, but will just jump to the previous call. Stepping through the code will show the current line executing and whats happening is obvious. You can force the situation by inserting a writeln("put this line in"); at the point you want to stop. I learned this by tracking execution of turboc programs with the debugger.
dave@tygra.ddmi.com (David Conrad) (01/10/91)
In article <1991Jan9.183514.7754@isis.cs.du.edu> nlarson@isis.UUCP (Neil Larson) writes: >In article <2394@bnlux0.bnl.gov> kushmer@bnlux0.bnl.gov (christopher kushmerick) writes: >>I am having what appears to be recurring and intermittant problems >>with the integrated debugger. I am trying to use the F-4 (run to cursor) >>command, and it reports that there is no code generated for this line. > >calculatecrc16(packet,crcval); >if crcval = 0 then > crcvalerror := true; >calculatecrc16(packet,crcval); > >the compiler will not create identical machine code for both calls to the >procedure calls, but will just jump to the previous call. What??!? Unh-uh. The if statement would get executed twice. The compiler won't do anything like that, thank von Neuman. There are some lines of source code for which no instructions are generated: repeat {this doesn't *do* anything, just a marker} ch := readkey; {calls readkey, places return value in ch} x := x + 5; {load x into register, add five, store to x} until ch = #27; {load ch, cmp with $1b, jne to top of loop} Now, the way the debugger sets breakpoints is by substituting an interrupt instruction for the first instruction at a particular line of source. The way F4-Go to cursor is implemented is by setting a breakpoint at the line to go to. But if no instructions are generated by the line, then there is nowhere to put the interrupt instruction. Hence the message. Now a *really* smart debugger would set a breakpoint at the next line which generates some code and set a flag somewhere indicating the actual source line to position the cursor at when the breakpoint was encountered. But that's a hefty kludge to workaround a pretty minor annoyance, eh? -- David R. Conrad dave@tygra.ddmi.com -- = CAT-TALK Conferencing Network, Computer Conferencing and File Archive = - 1-313-343-0800, 300/1200/2400/9600 baud, 8/N/1. New users use 'new' - = as a login id. AVAILABLE VIA PC-PURSUIT!!! (City code "MIDET") = E-MAIL Address: dave@DDMI.COM