Discussion:
Does ICAT understand watcom .sym files?
(too old to reply)
Andi B.
2019-12-28 14:10:20 UTC
Permalink
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
n***@efbe.prima.de
2019-12-29 16:39:43 UTC
Permalink
Post by 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.
...
Post by Andi B.
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
Lars Erdmann
2019-12-30 08:00:33 UTC
Permalink
Post by n***@efbe.prima.de
Post by 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.
...
Post by Andi B.
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
Marcel Mueller
2019-12-30 10:30:15 UTC
Permalink
Post by Lars Erdmann
Post by n***@efbe.prima.de
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
Andi B.
2019-12-30 13:34:55 UTC
Permalink
Post by n***@efbe.prima.de
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
Thanks Marcel. I even resigned myself in using the text mode wd.exe for this task. But
can't get it to work cause 'DosSMRegisterDD not allowed'. See my answer to Frank.

Andreas
Lars Erdmann
2019-12-30 16:24:07 UTC
Permalink
Oops, this is embarassing ...
I have never thoroughly read the WATCOM manual ...
Good to know, unfortunately ICAT is nothing that I would call "stable".

Lars
Post by Marcel Mueller
Post by Lars Erdmann
Post by n***@efbe.prima.de
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
Andi B.
2019-12-30 13:17:50 UTC
Permalink
Post by n***@efbe.prima.de
Post by 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.
...
Post by Andi B.
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
Thanks Lars for confirming this. So I can save my time to play even longer with CodeView
format.

Andi
Andi B.
2019-12-30 13:15:12 UTC
Permalink
Post by n***@efbe.prima.de
Post by 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.
...
Post by Andi B.
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
Lars Erdmann
2019-12-30 16:20:27 UTC
Permalink
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)


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
Post by Andi B.
Post by n***@efbe.prima.de
Post by 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.
...
Post by Andi B.
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
Andi B.
2019-12-31 12:16:54 UTC
Permalink
Hi Lars,
Post by Lars Erdmann
Hi Andy,
after fuzzing around with Watcom a little I think I now know how to set up the MUT and the
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 )
c:\os2\boot\mydriver.sys, mydriver.sys needs to contain native WATCOM debug info, I suppose)
Watcom remote debugging usually runs well here. I've setup my machines with netbios and so
the simplest setup is -

MUT> net use z: \\HOST\DriveShareWhichHoldsTestAppAndSources
MUT> Z:
MUT> netserv

HOST> wdw /tr=net TestApp

I develop on HOST and the TestApp runs on MUT without any file copying. Similar is
possible with TCP. Of course path to Watcom files has to setup right before. Sometimes I
need -

MUT> netserv xyz
HOST> wd /tr=net;xyz TestApp

as the HOST does not always release the server so need to start a new one. Or reboot.

Quite cool this Watcom remote debugging stuff. But as it even refuses to load this special
application (see below 'DosSMRegisterDD') useless in this case.

Andi

BTW Watcom debugger shortcommings -
1) Ugly font at least when using bigger screens. Unfortunately not configurable on our
platform.
2) Sometimes wdw windows have graphical distortions which leads to unreadable text.
3) Does not store session setups like breakpoints, watch windows, ...
Post by Lars Erdmann
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
Post by Andi B.
Post by n***@efbe.prima.de
Post by 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.
...
Post by Andi B.
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
Dave Yeo
2019-12-30 21:03:20 UTC
Permalink
Post by Andi B.
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
Andi B.
2019-12-31 11:57:24 UTC
Permalink
Post by Dave Yeo
Post by Andi B.
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
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.

Andreas
Dave Yeo
2019-12-31 20:10:40 UTC
Permalink
Post by Andi B.
Post by Dave Yeo
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.
OK, but then, assuming you're working with the SDK, you only have access
to old versions of pm.lib and no access to the drivers besides binaries.
Dave

Lars Erdmann
2019-12-30 08:14:09 UTC
Permalink
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
Post by 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.
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
Andi B.
2019-12-30 13:47:03 UTC
Permalink
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).
Yes I see this now too. Very limited but at least I see symbols for the functions I use. I
hadn't any clue what 'symbolic/symdeb' debugging means before. I'm used to source level
debugging since > 30 years. I didn't realize that that limited symbol info is all what I
can expect from ICAT running with .sym files.
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).
Not needless for me. I didn't think about that stuff well enough before. Thanks for
clarification.

Andreas
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
Post by 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.
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
Loading...