Eventually ICAT was developed. At first it only understood CodeView and
Visualage C debug formats. This was because the OS/2 version of
Microsoft C was used to develop many of the .ADD and .SYS device drivers.
CSet/2 and its successor VAC were used to develop VDD's.
More recently, .sym file support was added to ICAT.
The most efficient way to use ICAT is to place copies of your binaries and
the .sym files on the host and tell ICAT where they are. ICAT can get the
debug data from the MUT but it's a lot slower.
In an old thread Steven wrote -
Eventually ICAT was developed. At first it only understood CodeView and >>Visualage C debug formats. This was because the OS/2 version of
Microsoft C was used to develop many of the .ADD and .SYS device drivers. >>CSet/2 and its successor VAC were used to develop VDD's.
Anyone successfully run remote source level debugging with ICAT and
wcc386 and wlink?
Some time ago I tried to convince watcom to produce CodeView debugging information. But I didn't get working source level debugging with ICAT too.
Any hints to get ICAT source level debugging with watcom are welcome.
Regards, Andreas
In an old thread Steven wrote -
Eventually ICAT was developed. At first it only understood CodeView and >>Visualage C debug formats. This was because the OS/2 version of
Microsoft C was used to develop many of the .ADD and .SYS device drivers. >>CSet/2 and its successor VAC were used to develop VDD's.
More recently, .sym file support was added to ICAT.
The most efficient way to use ICAT is to place copies of your binaries and >>the .sym files on the host and tell ICAT where they are. ICAT can get the >>debug data from the MUT but it's a lot slower.
Unfortunately I can't get ICAT to work with my example file (part of a
bigger project) with debugging information.
I tried wlink with OP SYMFILE. The symfile is about 60k. When I start
the application on the MUT with this sym file it does not run. One of
the first statements in main() is printf. The printf statement seems to
be not reached when running under ICAT with the watcom sym file.
Next I created a symfile with Stevens mapsymw.pl script out of the map
file. This sym file is only 15k. Now my exe runs and shows the printf messages. But as before when I break with ICAT I do not see any symbolic information.
My ICAT is Version 4.06.00 which is the latest which I collected over
the years. It's from about 2002. Is there a newer version somewhere?
Anyone successfully run remote source level debugging with ICAT and
wcc386 and wlink?
Some time ago I tried to convince watcom to produce CodeView debugging information. But I didn't get working source level debugging with ICAT too.
Any hints to get ICAT source level debugging with watcom are welcome.
Regards, Andreas
Am 28.12.19 um 15:10 schrieb Andi B.:
In an old thread Steven wrote -
Eventually ICAT was developed. At first it only understood CodeView and
Visualage C debug formats. This was because the OS/2 version of
Microsoft C was used to develop many of the .ADD and .SYS device drivers. >>> CSet/2 and its successor VAC were used to develop VDD's.
...
Anyone successfully run remote source level debugging with ICAT and
wcc386 and wlink?
Some time ago I tried to convince watcom to produce CodeView debugging
information. But I didn't get working source level debugging with ICAT too. >>
Any hints to get ICAT source level debugging with watcom are welcome.
Regards, Andreas
Hello Andi,
What prevents using OW remote debugging?
What prevents using OW remote debugging?
ICAT does not understand OW native debugging format. When you let OW
generate Codeview debugging format instead, ICAT does not understand
that (newer) version of Codeview debugging format. Sigh ...
On 29.12.19 17.39, nospam_2019@efbe.prima.de wrote:
Am 28.12.19 um 15:10 schrieb Andi B.:
In an old thread Steven wrote -
Eventually ICAT was developed. At first it only understood CodeView and >>>> Visualage C debug formats. This was because the OS/2 version of
Microsoft C was used to develop many of the .ADD and .SYS device drivers. >>>> CSet/2 and its successor VAC were used to develop VDD's.
...
Anyone successfully run remote source level debugging with ICAT and
wcc386 and wlink?
Some time ago I tried to convince watcom to produce CodeView debugging
information. But I didn't get working source level debugging with ICAT too. >>>
Any hints to get ICAT source level debugging with watcom are welcome.
Regards, Andreas
Hello Andi,
What prevents using OW remote debugging?
ICAT does not understand OW native debugging format. When you let OW generate Codeview
debugging format instead, ICAT does not understand that (newer) version of Codeview
debugging format. Sigh ...
Lars
Am 28.12.19 um 15:10 schrieb Andi B.:
In an old thread Steven wrote -
Eventually ICAT was developed. At first it only understood CodeView and >>>Visualage C debug formats. This was because the OS/2 version of
Microsoft C was used to develop many of the .ADD and .SYS device drivers. >>>CSet/2 and its successor VAC were used to develop VDD's.
...
Anyone successfully run remote source level debugging with ICAT and
wcc386 and wlink?
Some time ago I tried to convince watcom to produce CodeView debugging
information. But I didn't get working source level debugging with ICAT too. >>
Any hints to get ICAT source level debugging with watcom are welcome.
Regards, Andreas
Hello Andi,
What prevents using OW remote debugging?
CU/2
Frank
Am 30.12.19 um 09:00 schrieb Lars Erdmann:
What prevents using OW remote debugging?
ICAT does not understand OW native debugging format. When you let OW generate Codeview
debugging format instead, ICAT does not understand that (newer) version of Codeview
debugging format. Sigh ...
There is no need for ICAT. The Watcom debugger can operate remote since the first day I
have seen it (a least for 25 years). The remote feature also works over platforms
boundaries, e.g. debug a Netware NLM from OS/2 or debug a 16 bit DOS driver in an OS/2 VDM
from OS/2 or even Windows.
Marcel
Have you placed the sym file into the same directoy on the HOST (where ICAT executes) as
the driver binary ? And have you modified the ICAT cmd file to point to that directory ?
Yes, I seem to remember that with the approach above, I had limited debugging capability
(with the wat2map.cmd and mapsym.exe approach).
Needless to say that sym file support is very restricted. It only knows public symbol
names, it has no clue of type definitions and no clue of stack variables. That also means that you should NOT mark any variables or routines as "static" if you want
to see their symbol names. "static" will prevent that symbol name from showing up in the
map file and consequently it will also be missing from the symbol file (check your map file).
What I have done in the past is write code that compiles with cl.exe (+ some assembler
code) or icc.exe (VAC) and compile+link with Codeview / HLL debug info. That'll allow to
do full source code debugging over ICAT.
Then, when everything works, you can switch over to Watcom.
Lars
On 28.12.19 15.10, Andi B. wrote:
In an old thread Steven wrote -
Eventually ICAT was developed. At first it only understood CodeView and
Visualage C debug formats. This was because the OS/2 version of
Microsoft C was used to develop many of the .ADD and .SYS device drivers. >>> CSet/2 and its successor VAC were used to develop VDD's.
More recently, .sym file support was added to ICAT.
The most efficient way to use ICAT is to place copies of your binaries and >>> the .sym files on the host and tell ICAT where they are. ICAT can get the >>> debug data from the MUT but it's a lot slower.
Unfortunately I can't get ICAT to work with my example file (part of a
bigger project) with debugging information.
I tried wlink with OP SYMFILE. The symfile is about 60k. When I start
the application on the MUT with this sym file it does not run. One of
the first statements in main() is printf. The printf statement seems to
be not reached when running under ICAT with the watcom sym file.
Next I created a symfile with Stevens mapsymw.pl script out of the map
file. This sym file is only 15k. Now my exe runs and shows the printf
messages. But as before when I break with ICAT I do not see any symbolic
information.
My ICAT is Version 4.06.00 which is the latest which I collected over
the years. It's from about 2002. Is there a newer version somewhere?
Anyone successfully run remote source level debugging with ICAT and
wcc386 and wlink?
Some time ago I tried to convince watcom to produce CodeView debugging
information. But I didn't get working source level debugging with ICAT too. >>
Any hints to get ICAT source level debugging with watcom are welcome.
Regards, Andreas
nospam_2019@efbe.prima.de schrieb:
Am 28.12.19 um 15:10 schrieb Andi B.:
In an old thread Steven wrote -
Eventually ICAT was developed. At first it only understood CodeView and >>>> Visualage C debug formats. This was because the OS/2 version of
Microsoft C was used to develop many of the .ADD and .SYS device
drivers.
CSet/2 and its successor VAC were used to develop VDD's.
...
Anyone successfully run remote source level debugging with ICAT and
wcc386 and wlink?
Some time ago I tried to convince watcom to produce CodeView debugging
information. But I didn't get working source level debugging with
ICAT too.
Any hints to get ICAT source level debugging with watcom are welcome.
Regards, Andreas
Hello Andi,
What prevents using OW remote debugging?
CU/2
Frank
Hi Frank,
nice to see you still hanging around here :-)
wdw.exe - beside the ugly fonts it uses you mean?
Starting "wdw /tr=net ..." shows a message 'DosSMRegisterDD not allowed'
(or similar). The same with wd.exe.
I try to debug gareport.exe. This is a CLI app which tries to detect the installed graphic card and it's capabilities via SNAP. Although the app
runs fine without PM I couldn't manage to debug it with OW. But it runs
under ICAT control.
Greetings, Andi
Am 30.12.19 um 09:00 schrieb Lars Erdmann:
What prevents using OW remote debugging?
ICAT does not understand OW native debugging format. When you let OW
generate Codeview debugging format instead, ICAT does not understand
that (newer) version of Codeview debugging format. Sigh ...
There is no need for ICAT. The Watcom debugger can operate remote since
the first day I have seen it (a least for 25 years). The remote feature
also works over platforms boundaries, e.g. debug a Netware NLM from OS/2
or debug a 16 bit DOS driver in an OS/2 VDM from OS/2 or even Windows.
Marcel
I try to debug gareport.exe. This is a CLI app which tries to detect the installed graphic card and it's capabilities via SNAP. Although the app
runs fine without PM I couldn't manage to debug it with OW. But it runs
under ICAT control.
On 12/30/19 05:15 AM, Andi B. wrote:
I try to debug gareport.exe. This is a CLI app which tries to detect the
installed graphic card and it's capabilities via SNAP. Although the app
runs fine without PM I couldn't manage to debug it with OW. But it runs
under ICAT control.
Rebuild it with VACPP?
Dave
Hi Andy,
after fuzzing around with Watcom a little I think I now know how to set up the MUT and the
host:
MUT (assuming its internet address is 192.168.178.220):
tcpserv -tr=tcp;192.168.178.220 3563
(this will start the server on the MUT that expects to receive debugging calls, it will
listen to port 3563 )
HOST (machine where WDW executes):
wdw /tr=tcp;192.168.178.220:3563 @Rc:\os2\boot\mydriver.sys
(the latter will try to access the driver binary on the MUT (@R) in directory c:\os2\boot\mydriver.sys, mydriver.sys needs to contain native WATCOM debug info, I suppose)
net use z: \\HOST\DriveShareWhichHoldsTestAppAndSources
Z:
netserv
netserv xyzHOST> wd /tr=net;xyz TestApp
You can freely choose the port number. Adjust the IP address (of the MUT) to match your
setup.
Let us know if that works for you. Obviously, you need to have WATCOM installed on both,
host and MUT.
Lars
On 30.12.19 14.15, Andi B. wrote:
nospam_2019@efbe.prima.de schrieb:
Am 28.12.19 um 15:10 schrieb Andi B.:
In an old thread Steven wrote -
Eventually ICAT was developed. At first it only understood CodeView and >>>>> Visualage C debug formats. This was because the OS/2 version of
Microsoft C was used to develop many of the .ADD and .SYS device
drivers.
CSet/2 and its successor VAC were used to develop VDD's.
...
Anyone successfully run remote source level debugging with ICAT and
wcc386 and wlink?
Some time ago I tried to convince watcom to produce CodeView debugging >>>> information. But I didn't get working source level debugging with
ICAT too.
Any hints to get ICAT source level debugging with watcom are welcome.
Regards, Andreas
Hello Andi,
What prevents using OW remote debugging?
CU/2
Frank
Hi Frank,
nice to see you still hanging around here :-)
wdw.exe - beside the ugly fonts it uses you mean?
Starting "wdw /tr=net ..." shows a message 'DosSMRegisterDD not allowed'
(or similar). The same with wd.exe.
I try to debug gareport.exe. This is a CLI app which tries to detect the
installed graphic card and it's capabilities via SNAP. Although the app
runs fine without PM I couldn't manage to debug it with OW. But it runs
under ICAT control.
Greetings, Andi
Rebuild it with VACPP?
Dave
Gareport is only a small part of the whole package. Of course I can
rebuild this simple tool with VAC and I've done it before. But what I
really want to debug is not this CLI program but the underlaying pm.lib
and driver code which it calls.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 88:42:34 |
| Calls: | 6,658 |
| Files: | 12,203 |
| Messages: | 5,333,956 |