JPI r1.06b 
Author Message
 JPI r1.06b

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 !

De{*filter*}s 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 de{*filter*} 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 de{*filter*} (this was used for breakpoints and single stepping).

So possibly the de{*filter*} 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 de{*filter*} 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



Sun, 04 Apr 1993 19:14:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. JPI r1.06b

2. Reply to Re: JPI V1.06b

3. JPI V1.06b

4. JPI V1.06B

5. JPI V1.06b

6. JPI M2 R1.06 MEMORY ALLOCATION

7. JPI Modula-2 v2.00 r1.04 under MS Windows 3.0

8. isforth version 1.06b released

9. Z/OS R1.2 manuals?

10. Add R3, R1 <-68000

11. accessing DOS memory with Smalltalk/V286 R1.1

12. : Digitalk Smalltalk V/286 R1.1, 1988

 

 
Powered by phpBB® Forum Software