OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Jochen Schäfer on August 12, 2019, 03:05:32 pm

Title: Which debugger to use.
Post by: Jochen Schäfer on August 12, 2019, 03:05:32 pm
I want to check, if things are still working as they should in DosBOX/2.
I tried Watcom, but GUI one instantly crashes, when I run DosBOX. The VIO one does not do that, but I can't find an option to select sources.
When I started the port about 15 years ago, I used one of the IBM debuggers in the VAC 4 package, but I just have not been able to set it up correctly at the moment, so I have to really should take a deep dive into them.

So my questions is: Which debugger are you using for GCC compiled and Watcom linked, rpm only applications?
Any configuration recommendations?
Title: Re: Which debugger to use.
Post by: Dave Yeo on August 12, 2019, 09:36:00 pm
Any of the IBM debuggers should sorta work, the OW ones won't. There are issues, IIRC the stack is slightly different then the native debuggers expect though generally they do seem to largely work.
For free and simple (textmode so you can run in full screen session to debug PM app) there is http://hobbes.nmsu.edu/download/pub/os2/dev/util/sd386v50.zip (http://hobbes.nmsu.edu/download/pub/os2/dev/util/sd386v50.zip). Better is if you can install VAC. such as 3.08 (winworld has a copy) or find a copy of jitdbg.
Title: Re: Which debugger to use.
Post by: Jochen Schäfer on August 13, 2019, 08:06:57 am
Thanks. I will try that.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 02, 2019, 02:20:32 am
Any of the IBM debuggers should sorta work, the OW ones won't. There are issues, IIRC the stack is slightly different then the native debuggers expect though generally they do seem to largely work.
For free and simple (textmode so you can run in full screen session to debug PM app) there is http://hobbes.nmsu.edu/download/pub/os2/dev/util/sd386v50.zip (http://hobbes.nmsu.edu/download/pub/os2/dev/util/sd386v50.zip). Better is if you can install VAC. such as 3.08 (winworld has a copy) or find a copy of jitdbg.

sd386 looks nice.  Are there any tutorials on its various features?  It has source code.  Has it been ported to any other OSes, so the OS/2 guest being debugged can be debugged from a Win32 or DOS or Linux host?
Title: Re: Which debugger to use.
Post by: Dave Yeo on November 02, 2019, 02:41:13 am
sd386 looks nice.  Are there any tutorials on its various features?  It has source code.  Has it been ported to any other OSes, so the OS/2 guest being debugged can be debugged from a Win32 or DOS or Linux host?

Not that I know off and considering it was replaced by graphical debuggers that likely ran on Windows, AIX and perhaps other systems, probably not, especially as the readme infers the remote debugging support was added just before being discontinued.
Note that to use any of the IBM debuggers with GCC, programs need to be linked with -Zomf as well as built with -g
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 02, 2019, 02:47:00 am
Any of the IBM debuggers should sorta work, the OW ones won't. There are issues, IIRC the stack is slightly different then the native debuggers expect though generally they do seem to largely work.

OW has remote TCP/IP-based debugging that the documentation states works across platforms like OS/2 to Win32.

Has anyone used it to know what works and what doesn't?

I'd like to get a cross-compiler to be able to code/test in a Win32 environment compiling for OS/2 binaries, copy to OS/2, and run there with remote debugging.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 02, 2019, 02:52:45 am
sd386 looks nice.  Are there any tutorials on its various features?  It has source code.  Has it been ported to any other OSes, so the OS/2 guest being debugged can be debugged from a Win32 or DOS or Linux host?

Not that I know off and considering it was replaced by graphical debuggers that likely ran on Windows, AIX and perhaps other systems, probably not, especially as the readme infers the remote debugging support was added just before being discontinued.

With source code available, a stub could probably be created, and the actual debugger app could be ported to another OS.

I never used to admire remote debugging, but I've had quite a bit of occasion the past couple years to do remote debugging over TCP/IP.  It's quite nice on a fast LAN.  And it's invaluable to be able to reach out to a client's system and diagnose their app errors from the comfort of my office, rather than driving to other cities. :-)

Quote
Note that to use any of the IBM debuggers with GCC, programs need to be linked with -Zomf as well as built with -g

I've had to use GCC when I've had to, but I've found GCC and GDB to be inferior debugging tools.  It's why I've done most of my development in Win32.  Visual Studio 2019 Community is free for up to 5 developers to use for proprietary / commercial work.  If you're an open source developer, it's free for any number whether proprietary or not.  It has features like edit-and-continue debugging, where you can change your source code while the program is running, apply code changes, and keep going.

There's no other development environment like it on the planet.  If there is, I'd like to see it.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 02, 2019, 03:06:27 am
sd386 looks nice ... It has source code.

The source code there is a treasure trove of useful information.  Incredibly exciting.

I wonder if any of  the developers are still available?  Maybe they'd like to teach me a thing or two about their work and goals.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 02, 2019, 04:20:38 pm
For free and simple (textmode so you can run in full screen session to debug PM app) there is http://hobbes.nmsu.edu/download/pub/os2/dev/util/sd386v50.zip (http://hobbes.nmsu.edu/download/pub/os2/dev/util/sd386v50.zip). Better is if you can install VAC. such as 3.08 (winworld has a copy) or find a copy of jitdbg.

Do you know what the license is for this product?  sd386v50.zip on Hobbes (http://hobbes.nmsu.edu/h-viewer.php?dir=/pub/os2/dev/util&file=sd386v50.zip&backto=%2Fh-browse.php%3Fdir%3D%2Fpub%2Fos2%2Fdev%2Futil)

I can't find any references to it in the source code.  Since it's been released in source code form, is it in the public domain?  This source code could serve as the base for a more comprehensive, more modern native/IBM-derived OS/2 debugger.
Title: Re: Which debugger to use.
Post by: Dave Yeo on November 02, 2019, 04:38:54 pm
It doesn't seem to have a license, which makes it weird to do much with.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 02, 2019, 06:58:38 pm
It doesn't seem to have a license, which makes it weird to do much with.

I'll use it as a guide and write new code in my style then.

But first I'll see if I can't get it to compile and ported to Win32 for remote debugging.  I could use it in a VM and debug into it that way.
Title: Re: Which debugger to use.
Post by: Dave Yeo on November 02, 2019, 07:03:31 pm
Wonder if Martin can use one of his IBM contacts to clarify the licensing? Also seems as it was publicly released with source and announced as abandoned, it would likely be fine to treat as public domain with the worst result being a cease and desist letter.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 03, 2019, 03:19:26 pm
Wonder if Martin can use one of his IBM contacts to clarify the licensing? Also seems as it was publicly released with source and announced as abandoned, it would likely be fine to treat as public domain with the worst result being a cease and desist letter.

Maybe so.  That'd be nice.

I really like sd386.  It's simple, fast.  Looks like it may be the precursor of what became Microsoft's CodeView Debugger for DOS and OS/2 when Microsoft split with IBM.

I cannot help but wonder what the OS world would've been like if IBM could've stuck in there and improved OS/2 for another ten years.

I haven't been able to get sd386 to compile yet.  I get close, but my dev environment isn't setup properly.  I'll have to figure out what it's missing one-by-one I think, and setup the PATH to create the correct environment.  NMAKE seems to work on the .MK script though.  The UNZIP utility I used also stuck an ASCII-26 at the end of every file, so it complains about those characters as well. : -)
Title: Re: Which debugger to use.
Post by: Dave Yeo on November 03, 2019, 05:23:11 pm
I really like sd386.  It's simple, fast.  Looks like it may be the precursor of what became Microsoft's CodeView Debugger for DOS and OS/2 when Microsoft split with IBM.

May well be. Looking, it seems to have been ported from an original 16 bit version

Quote
I cannot help but wonder what the OS world would've been like if IBM could've stuck in there and improved OS/2 for another ten years.

Probably have MS OS/2 v10, now with telemetry now. NT was originally OS/2 NT ver3 and I have a Byte news article somewhere where MS announced running 32 bit Presentation Manager on NT.

Quote
I haven't been able to get sd386 to compile yet.  I get close, but my dev environment isn't setup properly.  I'll have to figure out what it's missing one-by-one I think, and setup the PATH to create the correct environment.  NMAKE seems to work on the .MK script though.  The UNZIP utility I used also stuck an ASCII-26 at the end of every file, so it complains about those characters as well. : -)

Looks like it was meant to be compiled with C-Set/2, the precursor of VACPP. The CTRL-Z's are put in there by the editor, they're DOS EOF markers.
C-Set/2, http://www.edm2.com/index.php/IBM_C_Set/2 (http://www.edm2.com/index.php/IBM_C_Set/2) seems to be available at WinWorld, https://winworldpc.com/product/ibm-c-set/20 (https://winworldpc.com/product/ibm-c-set/20)
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 03, 2019, 07:02:37 pm
I cannot help but wonder what the OS world would've been like if IBM could've stuck in there and improved OS/2 for another ten years.

Probably have MS OS/2 v10, now with telemetry now. NT was originally OS/2 NT ver3 and I have a Byte news article somewhere where MS announced running 32 bit Presentation Manager on NT.

My thinking (hoping??) was IBM would've been a holdout against that deep state intrusion invasion.  Noble IBM ... victorious over evil. : -)
Title: Re: Which debugger to use.
Post by: Dave Yeo on November 03, 2019, 07:09:58 pm
Unluckily MS had pretty well full rights to the 32 bit code base. The WPS may be an exception but MS could use their own shell.
OTOH, IBM only had rights to Windows up to version 4, which is why Win95  was version 4.095. MS really didn't play nice back then.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 05, 2019, 02:57:41 am
Looks like it was meant to be compiled with C-Set/2, the precursor of VACPP. The CTRL-Z's are put in there by the editor, they're DOS EOF markers.
C-Set/2, http://www.edm2.com/index.php/IBM_C_Set/2 (http://www.edm2.com/index.php/IBM_C_Set/2) seems to be available at WinWorld, https://winworldpc.com/product/ibm-c-set/20 (https://winworldpc.com/product/ibm-c-set/20)

That worked.  It's compiling all of the .C files.  It's looking for masm386 to compile the assembly.

I've never seen a masm386.exe program.  Microsoft's Macro Assembler 6.x had a masm.exe program that translated the old command line to the new one used by ml.exe.

Any idea where to find masm386?
Title: Re: Which debugger to use.
Post by: David Graser on November 05, 2019, 03:51:09 am
Looks like it was meant to be compiled with C-Set/2, the precursor of VACPP. The CTRL-Z's are put in there by the editor, they're DOS EOF markers.
C-Set/2, http://www.edm2.com/index.php/IBM_C_Set/2 (http://www.edm2.com/index.php/IBM_C_Set/2) seems to be available at WinWorld, https://winworldpc.com/product/ibm-c-set/20 (https://winworldpc.com/product/ibm-c-set/20)

That worked.  It's compiling all of the .C files.  It's looking for masm386 to compile the assembly.

I've never seen a masm386.exe program.  Microsoft's Macro Assembler 6.x had a masm.exe program that translated the old command line to the new one used by ml.exe.

Any idea where to find masm386?

Hi Rick

Here is one I found.  However, it may be a later version than can be used.

https://cmeerw.org/prog/dm/rtl.html

There is an earlier version found on the following page dated 1989:

http://bytepointer.com/masm/index.htm



Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 05, 2019, 04:34:52 am
It's looking for masm386 to compile the assembly.  I've never seen a masm386.exe program.  Microsoft's Macro Assembler 6.x had a masm.exe program that translated the old command line to the new one used by ml.exe.
 Any idea where to find masm386?

Here is one I found.  However, it may be a later version than can be used.
https://cmeerw.org/prog/dm/rtl.html

There is an earlier version found on the following page dated 1989:
http://bytepointer.com/masm/index.htm

Hi, David! :-)

It looks the Digital Mars version is the same kind of command line / syntax converter.  And the Byte Pointer reference is for a Windows NT-based version.

Hmmm ...
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 05, 2019, 04:47:04 am
That worked.  It's compiling all of the .C files.  It's looking for masm386 to compile the assembly.

I've never seen a masm386.exe program.  Microsoft's Macro Assembler 6.x had a masm.exe program that translated the old command line to the new one used by ml.exe.

Any idea where to find masm386?

In looking at the .asm files, they appear to be standard Microsoft Macro Assembler source code files.  It might be a 386-version of masm.exe that it's calling.

Anyone know where I can get an OS/2 version of Microsoft Macro Assembler?  I have a DOS-based version of 6.11D I bought back in the 90s.  I was able to copy it over, and it runs some of the binp\ files, but ml.exe only exists in the bin\ area, and it thinks it's a DOS program launching in a DOS shell, rather than OS/2 shell.
Title: Re: Which debugger to use.
Post by: Dave Yeo on November 05, 2019, 05:43:22 am
There's masm v6 and masm v5. As for masm386, it seems to have shipped with MS OS/2 ver2 and perhaps in some of the early v2 toolkits/sdks. Possibly the oldest NT one might run on OS/2 as well.
The current toolkit also contains masm2alp.exe which might work.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 05, 2019, 06:11:39 am
There's masm v6 and masm v5. As for masm386, it seems to have shipped with MS OS/2 ver2 and perhaps in some of the early v2 toolkits/sdks.

Do you mean it shipped in the actual OS/2 retail box with the 3.5" floppies?

I have 2.0 ... and the floppy images for it.  I'll take a look tomorrow.  Thank you!
Title: Re: Which debugger to use.
Post by: Dave Yeo on November 05, 2019, 06:28:01 am
Note I said MS OS/2 ver 2, a very rare beta that was never released as far as I know, not IBM OS/2 ver 2 which is what you likely have.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 05, 2019, 12:22:43 pm
Note I said MS OS/2 ver 2, a very rare beta that was never released as far as I know, not IBM OS/2 ver 2 which is what you likely have.

Yes.  Missed that. :-)
Title: Re: Which debugger to use.
Post by: David Graser on November 05, 2019, 03:17:15 pm
Rick

I found these sites.

https://winworldpc.com/product/microsoft-os2-sdk/100

https://winworldpc.com/product/os-2-1x/10

https://www.pcjs.org/disks/pcx86/tools/microsoft/os2/sdk/1.02/
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 05, 2019, 04:55:54 pm
Rick

I found these sites.
https://winworldpc.com/product/microsoft-os2-sdk/100
https://winworldpc.com/product/os-2-1x/10
https://www.pcjs.org/disks/pcx86/tools/microsoft/os2/sdk/1.02/

Thank you, David.  They are helpful.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 06, 2019, 04:34:03 am
There's masm v6 and masm v5. As for masm386, it seems to have shipped with MS OS/2 ver2 and perhaps in some of the early v2 toolkits/sdks. Possibly the oldest NT one might run on OS/2 as well.
The current toolkit also contains masm2alp.exe which might work.

I still haven't been able to find masm386.exe.  I've tried IBM Macro Assembler from 1987 up thru Microsoft's Macro Assembler 6.0b.  They only have masm.exe.
Title: Re: Which debugger to use.
Post by: Dave Yeo on November 06, 2019, 04:39:18 am
You may have to port the assembly to a different assembler, perhaps jwasm (fork of wasm, the Open Watcom assembler) which IIRC is fairly compatible to masm.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 06, 2019, 04:52:56 am
You may have to port the assembly to a different assembler, perhaps jwasm (fork of wasm, the Open Watcom assembler) which IIRC is fairly compatible to masm.

I was wondering if masm386.exe is just masm.exe renamed?  MASM 6.x supported .486 and .586 in (at least in DOS).

Have you used masm2alp?  And alp?

IBM's Assembly Language Processor might be interesting to look at.  I see it comes with VisualAge 4, as well as in several standalone forms.

I see also in my searching for masm386.exe that IBM's Macro Assembler back in 1987 included CodeView, and some of their ALP packages included a "cv.exe" as well (don't know if it was CodeView or not, but probably so based on file size).
Title: Re: Which debugger to use.
Post by: Dave Yeo on November 06, 2019, 06:20:31 am
My reading is that MASM 6 supported i386 (and I guess i486 etc) but did not support the flat memory model.
Never used masm2alp or alp. Not really a programmer and about all I've done is porting assembly, mostly involving nasm. Simple stuff like the other day changing ".section rodate" to ".data" in some AS assembly (actually with ifdefs). The MASM386 code might just need some syntax fixes to port to another similar assembler and I do notice even going from MASM 5 to MASM 6 seems to take some work, at least going by the documentation.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 06, 2019, 12:11:53 pm
My reading is that MASM 6 supported i386 (and I guess i486 etc) but did not support the flat memory model.

MASM 6 was given the .flat memory model support for OS/2 (as I understand it).  The .tiny memory model is also technically flat, but limited to 64KB.

Quote
Never used masm2alp or alp. Not really a programmer and about all I've done is porting assembly, mostly involving nasm. Simple stuff like the other day changing ".section rodate" to ".data" in some AS assembly (actually with ifdefs). The MASM386 code might just need some syntax fixes to port to another similar assembler and I do notice even going from MASM 5 to MASM 6 seems to take some work, at least going by the documentation.

I'll try it tonight.  I have MASM 6.0b.  Will start there.
Title: Re: Which debugger to use.
Post by: Rick C. Hodgin on November 07, 2019, 12:02:58 am
I was wondering if masm386.exe is just masm.exe renamed?  MASM 6.x supported .486 and .586 in (at least in DOS).

I installed MASM 6.0b to c:\masm\binp and c:\masm\binb, and copied c:\masm\binb\masm.exe to c:\masm\binp\masm386.exe and ran nmake sd386.mk in the sd386src folder.  It worked!

I had to tweak a few of the assembly lines (a bug in MASM I assume, as that code is valid with an address override prefix byte):
Code: [Select]
; Did not work:
cmp byte ptr [di], 20h

; Changed to:
push edi
and edi,0ffffh
cmp byte ptr [edi], 20h
pop edi

And there were places like that in vbox.asm and putup.asm.

And it didn't recognize this in tcpip.c:
Code: [Select]
SOCECONNREFUSED
SOCEINTR
SOCENOTSOCK

I defined them all as -1 to see if it would compile and it did.  I'll find out their true values and update the code.

It also didn't find ilink.exe in the path, and it's not installed anywhere in my "dir /s ilink.exe" c:\ path.  I assume it's expecting a slightly newer version of icc than I have installed, and a version of MASM that includes the incremental linker.
Title: Re: Which debugger to use.
Post by: Dave Yeo on November 07, 2019, 01:41:30 am
Good to hear. Likely need the toolkit installed for ilink and nerror.h. You might have to update the network stuff to work with the 32 bit stack as it is too old to know about it. I have /os2tk45/h/nerror.h and /os2tk45/h/stack16/nerror.h here with those missing defines.