NU013809@NDSUVM1.BITNET (Greg Wettstein) (11/12/88)
I have just noticed what appears to be a bug in Codeview and am wondering if
anyone on the net has noticed a similar problem. First the hardware
configuration I have noted the problem on:
ALR 386/220 (80386 processor running at 20 Mhz)
2 Megabyte RAM
80 Megabyte hard disk - drive and controller unknown.
Packard Bell EGA video card
Phoenix 80385 BIOS 3.07.00 (Mirrored to RAM)
Packard Bell 2400 baud internal modem configured for COM2
1 Serial and 1 Parallel Port
Software configuration:
DOS 3.3
Codeview Version 2.2
MSC Version 5.1
QuickC Version 1.01
MS LINK Version 3.65 (? - Version number may not be exact but it is the
Linker supplied with MSC Version 5.1.
* All compiler software was installed with the SETUP program supplied
with MSC 5.1. Only the small model libraries were selected and
the emulator library was selected. (Presence of co-processor detected
at run-time and fixups generated, otherwise emulator code used for
floating point operations.)
Run-time Environemnet:
Config.sys entry: FILES = 20
No autoexec.bat file executed.
No memory resident programs active.
Problem:
A program was compiled using the small memory model with both MSC 5.1 and
QuickC 1.01. The program consisted of five modules each of which were
compiled independently with the following compiler command:
(Q)CL /Zi /Od /c (pname.c)
where pname is the filename of the source file.
The executable file was prepared by linking all five modules together with
the following linker command:
LINK /CODEVIEW /NOI p1+p2+p3+p4+p5,p1,p1.map,lib1.lib+lib2.lib
Where p1-p5 are the names of the modules and lib1-lib2 are object
code libraries prepared with MSC 5.1 and continuing various adjunct
functions.
The Codeview debugger was invoked with the following commands:
cv /r p1 * The /r switch instructs Codeview to use
the hardware debug registers for setting
cv /r /cgmain p1 tracepoint interrupts.
In the first case the program was than executed to the program entry point
with the following command: g main
In both cases after the startup code was executed returning to DOS with
the q command resulted in a system hang. The screen would go blank and
CTRL-BREAK would elicit no response. The system still seemed to be
servicing interrupts since pressing CTL-ALT-DEL would re-boot DOS.
The first function of this program is to display an entrance menu. When
execution was started with a simple go (g or F5) the program would display
display the menu and when the exit command was issued a 'program terminated
normally' prompt would be issued and at this time the 'q' command would be
result in a normal return to dos.
At first I thought this behavior simply resulted from returning to DOS
without executing the program termination code. I then allowed the program
to execute through several menu levels and then terminate. After this
process the computer would hang when a return to DOS was attempted.
Has anyone else experienced this difficulty while attempting to use the
hardware debug registers with Codeview? I have not tested the bug with
other programs but it is quite reproducible with this example. Removing
the /r switch when Codeview was executed resulted in complete alleviation
of the problem. I would appreciate comments from anyone who has
experienced this problem or knows of similar problems with other 80386
processors. Replys to either the net or by e-mail would be fine. Thanks
in advance.
As always,
G.W. Wettstein
NU013809@NDSUVM1