DOS ain't dead - Debugging and mapping functions (MS Linker)

lifelike

20.03.2025, 20:59

Debugging and mapping functions (MS Linker) (Developers)

Hello!

My first post. I am making slow progress on a problem, and was thinking
that if I post about it here maybe someone that knows more about this
stuff than me has something clever to say about it.

Trying to debug something in code that I compiled and linked using the toolchain that Microsoft posted last year together with the source code of MS-DOS 4.0 (here: https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/TOOLS).

The debugger I used for now is the one built into DOSBox-X (similar, I believe, to the one in the original DOSBox). It is difficult since I can't figure out the ___location of my functions (or data).

The linker (Microsoft Overlay Linker 3.65) generates a MAP-file that is mostly just lines like this:
1286:0BA2 _flip5
1286:0B7E _flip_range
31A6:3584 _flist_sel
1286:0E2C _fli_abs_tseek
21E5:0130 _fli_comp1
301E:0068 _fli_comp_frame

Very simple and nice file format, but quite useless without some tool that can tell me where each function ends up after I run the EXE and functions are relocated? Is there some free debugger that may be able to help? Or some trick to do this using the debugger in DOSBox? Setting breakpoints without knowing where the functions are is quite tedious.

I have resorted to breaking at interrupts instead and it works, but it would be more convenient to have a DOS debugger where I can just break at named functions.

Suggestions?

alexfru

USA,
21.03.2025, 05:02

@ lifelike

Debugging and mapping functions (MS Linker)

Post reply

...
> The linker (Microsoft Overlay Linker 3.65) generates a MAP-file that is
> mostly just lines like this:
> 1286:0BA2 _flip5
> 1286:0B7E _flip_range
> 31A6:3584 _flist_sel
> 1286:0E2C _fli_abs_tseek
> 21E5:0130 _fli_comp1
> 301E:0068 _fli_comp_frame
>
> Very simple and nice file format, but quite useless without some tool that
> can tell me where each function ends up after I run the EXE and functions
> are relocated?

I think those segments in the map file are relative to the base segment, where the EXE gets loaded. So, if you load the EXE into a debugger and note the base segment, you can then add the segment from the map file and that'll be the segment of the function or variable.

Alternatively, can you compile your code using the tiny memory model, where everything is in one segment?

lifelike

21.03.2025, 20:15

@ alexfru

Debugging and mapping functions (MS Linker)

Post reply

> I think those segments in the map file are relative to the base segment,
> where the EXE gets loaded. So, if you load the EXE into a debugger and note
> the base segment, you can then add the segment from the map file and
> that'll be the segment of the function or variable.
>
> Alternatively, can you compile your code using the tiny memory model, where
> everything is in one segment?

Unfortunately the program is in large memory model with code in multiple segments.

It seems as if all symbols that have the same segment in the EXE file end up with the same segment in RAM, but not sure if that is by design or just how it happened to be? I used that to find one function after locating another function that had the same segment in the MAP file. But that was a bit time-consuming.

tom

Germany (West),
22.03.2025, 21:58

@ lifelike

Debugging and mapping functions (MS Linker)

Post reply

> 1286:0BA2 _flip5
> 1286:0B7E _flip_range
> 31A6:3584 _flist_sel
> 1286:0E2C _fli_abs_tseek
> 21E5:0130 _fli_comp1
> 301E:0068 _fli_comp_frame

> Unfortunately the program is in large memory model with code in multiple
> segments.
By default, for C programs in the large memory model, every source file
gets its own code and data segment.

so all functions in one source module should get the same code segment,
like flip5, flip_range, fli_abd_tseek.

you can change this behavior and squeeze functions into
segments of your choice using

#pragma codeseg("FLIP_CODE")

or similar, depending on your compiler.

later, when linking multiple modules, the linker sorts all code segments first, then all data segments, and some more segment groups like "CONST", "STACK" and more.

> It seems as if all symbols that have the same segment in the EXE file end
> up with the same segment in RAM, but not sure if that is by design or just
> how it happened to be?
that's how it is.

at the beginning of your .exe file, there is a "relocation" table, meaning
"when loading the program into RAM at a certain address, please add this
address to these locations".
this offset is obviously the same for the entire program.

> I used that to find one function after locating
> another function that had the same segment in the MAP file. But that was a
> bit time-consuming.
yes. debuggers that understand the symbolic info of the compilers are cool.
luckily modern compilers usually come with an associated debugger.

CODEVIEW for MSC
WDB/WDEB386 for WCC
...

lifelike

25.03.2025, 23:16

@ tom

Debugging and mapping functions (MS Linker)

Post reply

> at the beginning of your .exe file, there is a "relocation" table, meaning
> "when loading the program into RAM at a certain address, please add this
> address to these locations".
> this offset is obviously the same for the entire program.
>
> > I used that to find one function after locating
> > another function that had the same segment in the MAP file. But that was
> a

Thanks for these pointers! I did some more searching and found some detailed explanations how the PSP works and how to find the segment the EXE was loaded to. That will be useful.

> CODEVIEW for MSC
> WDB/WDEB386 for WCC
> ...

Yes... I know I make things difficult for myself, but my project involves trying to make something with the toolchain that Microsoft kindly included in their 2024 release of MS-DOS 4.0. Unfortunately they did not include CODEVIEW.

https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/TOOLS

Besides using the DOSBox-X debugger is (other than the lack of symbols) convenient compared to running a debugger inside of DOS. Especially since it is an application with graphics.

Japheth

Germany (South),
26.03.2025, 05:03
(edited by Japheth, 26.03.2025, 12:35)

@ lifelike

Debugging and mapping functions (MS Linker)

Post reply

> Besides using the DOSBox-X debugger is (other than the lack of symbols)
> convenient compared to running a debugger inside of DOS. Especially since
> it is an application with graphics.

IIRC DOSBox-x supports a secondary display for DOS (usually MDA). Both CodeView and Open Watcom WD may use that.

EDIT: This feature was even discussed here in this forum: https://www.bttr-software.de/forum/forum_entry.php?id=19332

---
MS-DOS forever!

marcov 26.03.2025, 11:03 @ Japheth	Debugging and mapping functions (MS Linker) Post reply
	> IIRC DOSBox-x supports a secondary display for DOS (usually MDA). Both > CodeView and Open Watcom WD may use that. Back in the day I had a secondary monochrome VGA. IIRC both Borland and Topspeed toolchains could work with that.

lifelike

27.03.2025, 20:02

@ Japheth

Debugging and mapping functions (MS Linker)

Post reply

> > Besides using the DOSBox-X debugger is (other than the lack of symbols)
> > convenient compared to running a debugger inside of DOS. Especially
> since
> > it is an application with graphics.
>
> IIRC DOSBox-x supports a secondary display for DOS (usually MDA). Both
> CodeView and Open Watcom WD may use that.
>
> EDIT: This feature was even discussed here in this forum:
> https://www.bttr-software.de/forum/forum_entry.php?id=19332

Thanks! Have to try that some day.

The only thing I could find about it was this issue from 2021 that is still open:
https://github.com/joncampbell123/dosbox-x/issues/1075

ecm

Düsseldorf, Germany,
26.03.2025, 09:59

@ lifelike

Debugging and mapping functions (MS Linker)

Post reply

> Besides using the DOSBox-X debugger is (other than the lack of symbols)
> convenient compared to running a debugger inside of DOS. Especially since
> it is an application with graphics.

Some debuggers support connecting to a serial port for their terminal I/O, such as lDebug. Very useful to debug graphical applications.

---
l

Rugxulo Usono, 21.03.2025, 06:20 @ lifelike	Debugging and mapping functions (MS Linker) Post reply
	https://ladsoft.tripod.com/grdb_debugger.html > GRDB has built in support for symbol tables. One way of getting > the symbol tables is by using the MKSYM program to parse a map > file from one of the major assemblers. The VALX linker, which > is distributed as part of the CC386 compiler package, also is > able to generate the kinds of symbol tables GRDB uses.

lifelike

21.03.2025, 20:12

@ Rugxulo

Debugging and mapping functions (MS Linker)

Post reply

> https://ladsoft.tripod.com/grdb_debugger.html
>
> > GRDB has built in support for symbol tables. One way of getting
> > the symbol tables is by using the MKSYM program to parse a map
> > file from one of the major assemblers. The VALX linker, which
> > is distributed as part of the CC386 compiler package, also is
> > able to generate the kinds of symbol tables GRDB uses.

Thanks! Running MKSYM and then GRDB worked. I can find my functions. However since it is a graphical application I try to test it gets a bit messy and ruins the screen. A dual-monitor set up with a monochrome monitor for debugging seems possible, but I am not sure if any emulator supports that?

Back to my workaround with hardcoding some interrupt calls in the code I want to have breakpoints in for now.