Does ICAT understand watcom .sym files?

7 views
Skip to first unread message

Andi B.

unread,
Dec 28, 2019, 9:10:21 AM12/28/19
to
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

nospa...@efbe.prima.de

unread,
Dec 29, 2019, 11:39:45 AM12/29/19
to
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

Lars Erdmann

unread,
Dec 30, 2019, 3:00:35 AM12/30/19
to
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

Lars Erdmann

unread,
Dec 30, 2019, 3:14:11 AM12/30/19
to
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

Marcel Mueller

unread,
Dec 30, 2019, 5:30:16 AM12/30/19
to
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

Andi B.

unread,
Dec 30, 2019, 8:15:12 AM12/30/19
to
nospa...@efbe.prima.de schrieb:
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.

unread,
Dec 30, 2019, 8:17:50 AM12/30/19
to
Lars Erdmann schrieb:
Thanks Lars for confirming this. So I can save my time to play even longer with CodeView
format.

Andi

Andi B.

unread,
Dec 30, 2019, 8:34:54 AM12/30/19
to
Marcel Mueller schrieb:
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

Andi B.

unread,
Dec 30, 2019, 8:47:04 AM12/30/19
to
Lars Erdmann schrieb:
> 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

Lars Erdmann

unread,
Dec 30, 2019, 11:20:35 AM12/30/19
to
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

Lars Erdmann

unread,
Dec 30, 2019, 11:24:09 AM12/30/19
to
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

Dave Yeo

unread,
Dec 30, 2019, 4:03:22 PM12/30/19
to
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

Andi B.

unread,
Dec 31, 2019, 6:57:25 AM12/31/19
to
Dave Yeo schrieb:
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


Andi B.

unread,
Dec 31, 2019, 7:16:56 AM12/31/19
to
Hi Lars,

Lars Erdmann schrieb:
> 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)

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, ...

Dave Yeo

unread,
Dec 31, 2019, 3:10:41 PM12/31/19
to
On 12/31/19 03:57 AM, Andi B. wrote:
>> 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
Reply all
Reply to author
Forward
0 new messages