Path: utzoo!attcan!uunet!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!zephyr.ens.tek.com!tektronix!nosun!qiclab!m2xenix!puddle!f15.n491.z5.fidonet.org!Ian.Macintosh
From: Ian.Macintosh@f15.n491.z5.fidonet.org (Ian Macintosh)
Newsgroups: comp.lang.modula2
Subject: JPI r1.06b
Message-ID: <131.271DBBCE@puddle.fidonet.org>
Date: 17 Oct 90 11:14:00 GMT
Sender: ufgate@puddle.fidonet.org (newsout1.26)
Organization: FidoNet node 5:491/15 - West Rand Clan, Randfontein RSA
Lines: 39

On <11 Oct 1990 21:02>, Cobus Debeer wrote to All:

 CD>LONGREAL with a co-processor present.  When I enable the 
 CD>generation of debug information, something goes wrong.  The code 
 CD>geneted works on the first pass through the code but on 
 CD>subsequent passes ( eg the second time through a loop ) 
 CD>something goes wrong.  The machine crashes and I traced the 
 CD>cause to an INT 0DD instruction in the program.  The strange 
 CD>part is that the INT instruction is not there on the first pass 
 CD>through the code.  Initially I suspected that the destination of 
 CD>a jump is calculated incorrectly and that the code is 'out of 
 CD>phase' causing good code to become garbage.  When I examine the 
 CD>memory before executing the code I see good code.  I noted down 
 CD>the data at the relevant address and stepped through the code 
 CD>until I observe the INT.  I examined the memory again and lo and 
 CD>behold, it was changed.  I now suspect that VID has a dangling 
 CD>pointer and that it clobbers my program at some point in time.
 CD> 
 CD>However, when I compile the code without debug information, it 
 CD>works. (sometimes )  When I turn on the run time error checking 
 CD>then the program again crashes without message and hangs the 
 CD>machine.  I am lost !

Debuggers that handle machine language use some technique to stop your program after it has executed an instruction.  On the 80XXX family you could use the special int/instruction built into the CPU for this purpose (I forget how it works exactly, and I'm too lazy to go find the data), or you can use another technique that used to be very prominent in CPU's without this capability.

What the debugger did, was dissasemble the next instruction and then after determining the exact byte length, replace the next byte(s) with an int or call to the debugger (this was used for breakpoints and single stepping).

So possibly the debugger is the cause of the problem?  You could verify this by creating a breakpoint in the data area of a test program, and then execute the program which will output the contents of the breakpoint address.  If you get the Int 0DD bytes there, you got dat bug.

If you find a Bug there, squashing him might prove difficult, so consider another debugger if at all possible (I have never use M2 before, so I haven't the foggiest idea of what the debugging process entails there)

Regards,

Ian.


--  
uucp: uunet!m2xenix!puddle!5!491!15!Ian.Macintosh
Internet: Ian.Macintosh@f15.n491.z5.fidonet.org