Author Topic: FreeDOS's DEBUG.EXE - Is there a way to set a *.ASM file dependent breakpoint?  (Read 433 times)

bugthis

  • Regular Member
  • *
  • Posts: 37
I am using FreeDOS's DEBUG.EXE for debugging and JWASMR.EXE to assemble assembly source code files *.asm.

I know, that DEBUG.EXE is there to be as compatible to MS-DOS's DEBUG.EXE as possible, but is there a way to set a breakpoint depending on a *.asm source code file that is passed to debug when debug is run?

Let's say i have an ASM source code in file hello.asm and i want set a breakpoint in line number 10 and the compiled file is hello.exe is there a feature to pass on besides the binary executable also the source code
and the line number to set a breakpoint in DEBUG?

What i like to have is something like this, starting debug like this:
DEBUG.EXE programfile sourcefile breakpoint_number
debug.exe hello.exe hello.asm 10

Is this possible?
Or is there another way to make DEBUG.EXE use a ASM source code file to set breakpoints?
I ask because setting breakpoints the normal way in DEBUG.EXE is quite cumbersome.


_japheth

  • Member
  • **
  • Posts: 115
What i like to have is something like this, starting debug like this:
DEBUG.EXE programfile sourcefile breakpoint_number
debug.exe hello.exe hello.asm 10

Is this possible?

Not with DEBUG - "symbolic debugging" isn't supported.

The most basic tool that allows symbolic debugging is MS symdeb, the predecessor of CodeView, like DEBUG a line oriented debugger, very ancient.

The tool chain for symbolic debugging with symdeb looks like this:

1. jwasm -Zd hello.asm
2. link /li /map hello.obj;
3. mapsym hello.map
4. symdeb hello.sym hello.exe

It still works, I just tested it with this source (hello.asm):

Code: [Select]
.286
.model tiny
.stack 1024
.dosseg

public text1

.data

text1 db "hello",13,10,'$'

.code
start:
mov ax, @data
mov ds, ax
assume ds:dgroup
mov dx, offset text1
mov ah, 9
int 21h
mov ax,4c00h
int 21h

END start

Note that the source must contain at least ONE symbol.declared as public!
The most important lacking feature of symdeb is that it doesn't support 80386+ cpus

Quote
Or is there another way to make DEBUG.EXE use a ASM source code file to set breakpoints?
I ask because setting breakpoints the normal way in DEBUG.EXE is quite cumbersome.

No.
Dummheit, gepaart mit Dreistigkeit - eine furchtbare Macht.

bugthis

  • Regular Member
  • *
  • Posts: 37
Not with DEBUG - "symbolic debugging" isn't supported.

The most basic tool that allows symbolic debugging is MS symdeb, the predecessor of CodeView, like DEBUG a line oriented debugger, very ancient.

Thank you for your answer. That is sad to hear. Unfortunately I don't have SYMDEB or CodeView.

Will FreeDOS's DEBUG.EXE support symbolic debugging in future? Is this a planned feature?

Now i also know, what SID86.EXE from Digital Research (DR-DOS) does better than Microsoft's  DEBUG.EXE, it does support symbolic debugging.

From the users guide:
Quote
SID-86  is a powerful symbolic debugger designed for use with the CP/M-86 and
MP/M-86 operating systems. It expands on the features of the standard CP/M-86
debugger,  DDT-86,  allowing users to test and debug  programs interactively.
SID-86  includes  symbolic  assembly and  disassembly,  expressions involving
hexadecimal,  decimal, ASCII, and symbolic values, permanent breakpoints with
pass  counts,  and trace without call. You should be familiar with  the Intel
8086  processor,  ASM-86  and  the CP/M-86 or  MP/M-86  operating  system, as
described in the "CP/M-86 Operating System System Guide" or "MP/M-86 Operating
System System Guide".
http://www.cpm.z80.de/manuals/SID86_User_Guide.txt


Quote
The tool chain for symbolic debugging with symdeb looks like this:

1. jwasm -Zd hello.asm
2. link /li /map hello.obj;
3. mapsym hello.map
4. symdeb hello.sym hello.exe

Unfortunately, I don't have LINK.EXE either. It is not part of MS-DOS 6.x which i have. The last MS-DOS version with which it was delivered was probably MS-DOS 4.x and I don't have that or an older version.

However, FreeDOS comes with the Watcom C compiler and it has WLINK.EXE as the linker. This is the linker I've used so far to include object files.
Now I just need to figure out what the comparable parameters are to use symbolic debugging. Those from LINK.EXE understandably don't work with WLINK.EXE

And then I would still have to test SID86.EXE, which I have with DR-DOS 3.41, whether it is compatible with the JWASM parameter -Zd and its output. If so, then I would have a symbolic debugger I could use.

Or does the Watcom C Compiler Suite provide a better debugger alternative with symbolic debugging support?

Quote
It still works, I just tested it with this source (hello.asm):
..

Note that the source must contain at least ONE symbol.declared as public!
The most important lacking feature of symdeb is that it doesn't support 80386+ cpus
Thank you, i will test that as soon as i have a working tool chain.

_japheth

  • Member
  • **
  • Posts: 115
Will FreeDOS's DEBUG.EXE support symbolic debugging in future? Is this a planned feature?

No.

Quote
Now i also know, what SID86.EXE from Digital Research (DR-DOS) does better than Microsoft's  DEBUG.EXE, it does support symbolic debugging.

Yes - if you'll manage to make it work...


Quote
However, FreeDOS comes with the Watcom C compiler and it has WLINK.EXE as the linker. This is the linker I've used so far to include object files.
Now I just need to figure out what the comparable parameters are to use symbolic debugging. Those from LINK.EXE understandably don't work with WLINK.EXE

The Watcom debugger has symbolic debugging capabilities and works quite well. It's a bit biased towards C, however. Your assembly program must have e public "main" proc, and memory model TINY won't work. Also, it's a "full-screen" application like CodeVIew - personally, I prefer the debuggers with a simple line interface.

The tool chain is:
jwasm -Zi hello.asm
wlink debug c format dos file hello.obj op cvp

and then just run: wd hello.exe

If it doesn't work, try jwlink instead of wlink. IIRC, I fixed a bug in the open watcom Codeview format handler for jwlink.



Dummheit, gepaart mit Dreistigkeit - eine furchtbare Macht.

bugthis

  • Regular Member
  • *
  • Posts: 37
Quote
Now i also know, what SID86.EXE from Digital Research (DR-DOS) does better than Microsoft's  DEBUG.EXE, it does support symbolic debugging.

Yes - if you'll manage to make it work...
I will try.
But first i need to learn the command syntax. It is quite different to DEBUG.EXE


Quote
The Watcom debugger has symbolic debugging capabilities and works quite well. It's a bit biased towards C, however. Your assembly program must have e public "main" proc, and memory model TINY won't work. Also, it's a "full-screen" application like CodeVIew - personally, I prefer the debuggers with a simple line interface.

The tool chain is:
jwasm -Zi hello.asm
wlink debug c format dos file hello.obj op cvp

and then just run: wd hello.exe

If it doesn't work, try jwlink instead of wlink. IIRC, I fixed a bug in the open watcom Codeview format handler for jwlink.

Thank you. I will try that.

bugthis

  • Regular Member
  • *
  • Posts: 37
The Watcom debugger has symbolic debugging capabilities and works quite well. It's a bit biased towards C, however. Your assembly program must have e public "main" proc, and memory model TINY won't work. Also, it's a "full-screen" application like CodeVIew - personally, I prefer the debuggers with a simple line interface.

The tool chain is:
jwasm -Zi hello.asm
wlink debug c format dos file hello.obj op cvp

and then just run: wd hello.exe
Thanks. I tried that today, but DOS4G/W throws an exception (error 2001) when i try to load my Real Mode program.

I used SMALL, C for .MODEL
Code: [Select]
PUBLIC MAIN
.MODEL SMALL, C
.STACK 256
.DOSSEG

.CODE

MAIN:
 ....
END MAIN

Quote
If it doesn't work, try jwlink instead of wlink. IIRC, I fixed a bug in the open watcom Codeview format handler for jwlink.
jwlink isn't shipped with FreeDOS.
Thus i downloaded the DOS binary from:
https://www.japheth.de/Download/JWlink/JWlink_v19b13_dos.zip

And did what you said.
But wd crashes with the same message.

_japheth

  • Member
  • **
  • Posts: 115
Thanks. I tried that today, but DOS4G/W throws an exception (error 2001) when i try to load my Real Mode program.

No idea what's that's supposed to mean. But it may shed light on the reason why I prefer simple tools without "tons of features" ...

Quote
Thus i downloaded the DOS binary from:
https://www.japheth.de/Download/JWlink/JWlink_v19b13_dos.zip

That's an outdated link, containing very old and obsolete binaries. But it doesn't matter, using an up-to-date jwlink most likely won't fix the WD "exception".
Dummheit, gepaart mit Dreistigkeit - eine furchtbare Macht.

bugthis

  • Regular Member
  • *
  • Posts: 37
Now i also know, what SID86.EXE from Digital Research (DR-DOS) does better than Microsoft's  DEBUG.EXE, it does support symbolic debugging.

Yes - if you'll manage to make it work...
I took a closer look at SID in the last few days.
What I found out so far is that SID expects *.SYM files as symbol files.
They are loaded by passing two arguments to SID at the command line
Where the first is the program file and the second is a *.sym file.

Code: [Select]
SID program symfile
Besides that, i found out, that SID86 was also shipped with a suite called DRI Programmer's Utilities.
This suite also included an assembler called rasm86.exe, a linker link86.exe, a tool lib86.exe to create libraries and xref86.exe to create some documentation for printing.
 
The manual gave some informations about the object file format that is used by the assembler and that SID86 understands.
On page 3 of the manual it is stated, that the assembler does use the Intel Object Module Format.
https://bitsavers.org/pdf/digitalResearch/concurrent/1065-2043-001_Programmers_Utilities_Guide_For_Concurrent_DOS_86_Expanded_Memory_XM_Nov1986.pdf

I don't know, if JWASM can generate it or if this is the same, as -omf which is created by default.
https://www.japheth.de/JWasm/Manual.html#CHAPOUTPUTFORMATS

The problem is now, that i don't know how to create a *.sym file with JWASM?

Also i found another big problem or bug. SID86 can read and debug every *.EXE file out there, with the exception of those, i created with JWASM and the -mz parameter.
I really don't know why that is.
When trying to load such a file, SID prints the error "insufficient memory" but the file i used as an example is only 62 bytes in size. Thus it is definitely not a memory issue, it's more some kind of incompatibilities.

*.COM files that where created with the -bin parameter with JWASM can be loaded with SID on the other hand and debugged with SID. I don't know why it fails at JWASM's EXE files and passes at other EXE files that were not created with JWASM.

The biggest difference between SID and DEBUG was, that you have to use the command "tw" inside SID to step over interrupts and other routines, this is similar to DEBUG's "P" command. If you don't do that, it's like a simple "T" command in DEBUG, which will result in stepping into an interrupt and going bogus.

The registers can be shown with the command "X" instead of "R".
To show the disassembly code you must press "L" for list, instead of "U" for unassembly.

A disadvantage of SID is that the assembler mnemonics that appear after a "T" step in a program do not represent the mnemonics that SID will run next, but rather the one that was already ran.
The mnemonic of the next command to be executed is not displayed, only the address is displayed and if you want to know the mnemonic of the next command, you must use the list "L" command to display it.
This is quite cumbersome and solved better in DEBUG, where the next command is shown with each "T" step.

The rest is quite similar, with the exception that SID is in some way much more powerful than DEBUG and the flag register output is much easier to read.

_japheth

  • Member
  • **
  • Posts: 115
The manual gave some informations about the object file format that is used by the assembler and that SID86 understands.
On page 3 of the manual it is stated, that the assembler does use the Intel Object Module Format.
I don't know, if JWASM can generate it or if this is the same, as -omf which is created by default.

Yes, this format is pretty well documented.

Quote
The problem is now, that i don't know how to create a *.sym file with JWASM?

.SYM files can be created only alter/during the link step. Although jwasm acts as a "micro" linker when using -mz or -bin options, it doesn't output .SYM files - and I doubt that there's a standard/documented format for such files.

Quote
Also i found another big problem or bug. SID86 can read and debug every *.EXE file out there, with the exception of those, i created with JWASM and the -mz parameter.

Should be no problem - just don't use the -mz option and let the DR tools do the link step.
Dummheit, gepaart mit Dreistigkeit - eine furchtbare Macht.