#107 DEBUG - Verify values of last file loaded

[Oliver]

If you load a program in Digital Research's SID86 debugger, you will receive information about the start and end address of the program after loading.

  Start      End
0917:0000 0917:07FF

This output can be obtained again in SID86with the V command.

#V
  Start      End
0917:0000 0917:07FF

In DEBUG from FreeDOS no such information is shown.
The only information you have is in the segment registers, but these values
can change. To obtain them again, you have to use the command L.
But theL command does only reload the registers with the correct values,
but these values do not mean, that it is the starting address of the whole
memory the program needs.

In the above SIDexample, the starting address is 0917:0000 but the code
starts at 0917:0400 which means 0917:0000 till 0917:03FF is probably used
for the Stack. SS points at0917 and SP at 037B.
The stack is thus 1024 Bytes in this example large.
The same program in DEBUG the SSand CS have the same value

SID therefore saves the start and end addresses separately and can use the Vcommand to display them even if the values in the segment registers have changed.

A similar function to show the start and end address would be desirable for FreeDOS' DEBUG.

[E. C. Masloch]

In lDebug, FreeDOS Debug/X, and MS-DOS Debug you get the initial bx:cx register value after an L command which indicates the size of a flat-format executable or non-executable binary file. (In lDebug display this using h bxcx.) This may be incompatible to how MZ .EXE files and .HEX files are handled, but for .COM files the register pair should give the size of the file. The starting location of the file is at PSP:100h in this case, equal to cs:ip.

If we were to add a command like SID's V we would need to nail down exactly what is considered the start and end addresses.

[Oliver]

Thank you for the information.
I tried that with a current version of LDEBUG.
LDEBUG.COM has a file size of 77824 Bytes on a floppy image, but when loading LDEBUG.COM with LDEBUG i get the following for

h bxcx
000120300  decimal: 73776

I also tried to check the size of my simple hello world program, which is an MZ EXE.
On floppy disk, it does have a size of 89 bytes.
In LDEBUG, when i try to unassemble the program bytes i count 22 Bytes for the code.
The "Hello World!$" string and the additional new line "#$" give me 13 + 2 = 15 bytes.
So the sum should be 22 Bytes + 15 Bytes = 37 Bytes.
I don't know that the other 89 Bytes - 37 Bytes are, but LDEBUG prints a:

-h bxcx
0029  decimal: 41

[E. C. Masloch]

The ldebug.com file is actually an MZ .EXE-style executable under the hood. Try running ldebug /F ldebug.com to load the file as if it was a flat-format binary.

The other example is also somewhat expected for an MZ .EXE file. If you want me to look into it more, comment here with a hexdump of the file please.

[Oliver]

The /F option worked for ldebug.com.

Here's the hexdump, i removed the # in my hello world program to make it a little smaller.

0000000 5a4d 0058 0001 0001 0003 0003 ffff 0003
0000010 0020 0000 0000 0000 001e 0000 0000 0001
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000030 01b8 8e00 bad8 0008 09b4 21cd 15ba b400
0000040 cd09 b421 cd4c 6121 6548 6c6c 206f 6f57
0000050 6c72 2164 0d24 240a                    
0000058

source code:

; Filename: HELLO.ASM
.MODEL SMALL, C
.STACK 32
.DATA
  STRING DB "Hello World!$"
  ENDL   DB 0Dh, 0Ah, 24h  ; CRLF + "$"

.CODE
START: MOV AX, @DATA
       MOV DS, AX

       MOV DX, OFFSET STRING
       MOV AH, 09h
       INT 21h
       MOV DX, OFFSET ENDL
       MOV AH, 09h
       INT 21h

       MOV AH, 4Ch           ; Return to DOS
       INT 21h 
       END START

It compiles fine with JWASMR:

jwasmr -mz hello.asm

[E. C. Masloch]

This is what I get when loading your program into lDebug, with and without the /F switch:

G:\>ldebug /f hello.exe
-r
AX=0000 BX=0000 CX=0058 DX=0000 SP=01FE BP=0000 SI=0000 DI=0000
DS=20C8 ES=20C8 SS=9FDF CS=20C8 IP=0100 NV UP EI PL ZR NA PE NC
20C8:0100 4D                dec     bp
-d cs:ip l bxcx
20C8:0100  4D 5A 58 00 01 00 01 00-03 00 03 00 FF FF 03 00 MZX.............
20C8:0110  20 00 00 00 00 00 00 00-1E 00 00 00 00 00 01 00  ...............
20C8:0120  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
20C8:0130  B8 01 00 8E D8 BA 08 00-B4 09 CD 21 BA 15 00 B4 ...........!....
20C8:0140  09 CD 21 B4 4C CD 21 00-48 65 6C 6C 6F 20 57 6F ..!.L.!.Hello Wo
20C8:0150  72 6C 64 21 24 0D 0A 24-                        rld!$..$
-q
G:\>ldebug hello.exe
-r
AX=0000 BX=0000 CX=0028 DX=0000 SP=0020 BP=0000 SI=0000 DI=0000
DS=20DD ES=20DD SS=20F0 CS=20ED IP=0000 NV UP EI PL ZR NA PE NC
20ED:0000 B8EE20            mov     ax, 20EE
-d cs:ip l bxcx
20ED:0000  B8 EE 20 8E D8 BA 08 00-B4 09 CD 21 BA 15 00 B4 .. ........!....
20ED:0010  09 CD 21 B4 4C CD 21 00-48 65 6C 6C 6F 20 57 6F ..!.L.!.Hello Wo
20ED:0020  72 6C 64 21 24 0D 0A 24-                        rld!$..$
-u cs:ip l #23
20ED:0000 B8EE20            mov     ax, 20EE
20ED:0003 8ED8              mov     ds, ax
20ED:0005 BA0800            mov     dx, 0008
20ED:0008 B409              mov     ah, 09
20ED:000A CD21              int     21
20ED:000C BA1500            mov     dx, 0015
20ED:000F B409              mov     ah, 09
20ED:0011 CD21              int     21
20ED:0013 B44C              mov     ah, 4C
20ED:0015 CD21              int     21
-

This gives 23 bytes for code, 1 zero byte of alignment I assume, plus 16 bytes of data. 40 bytes in total, matching cx = 28h. This only covers the program image of the executable, not its MZ .EXE header. 30h bytes are used by the header, which must end on a paragraph boundary.

[Oliver]

Thank you for your answer.

[E. C. Masloch]

I recently added an Extension for lDebug as requested by another user per email. It is called linfo.eld and once installed like ext linfo.eld install it will display information on an executable file when it is being loaded:

~-ext linfo.eld install  
LINFO installed.
~-linfo probe
LINFO, file size = 375 (0177h), no EXE header
PSP at segment = 598Eh, memory block size is  281 KiB
~-l
Loading file: DPMIMINI.COM
DPMI entry hooked, new entry=2FC0:52FE
LINFO: Success
LINFO, file size = 375 (0177h), no EXE header
PSP at segment = 598Eh, memory block size is  281 KiB
~-linfo file 
Loading file: DPMIMINI.COM
~-linfo probe
LINFO, file size = 375 (0177h), no EXE header
PSP at segment = 598Eh, memory block size is  281 KiB
~-k lcdebugx.com
~-l
Loading file: LCDEBUGX.COM
LINFO: Success
LINFO, file size = 96256 (017800h), EXE header signature = MZ
Header size = 4048 (00FD0h), image size = 92208 (016830h)
PSP at segment = 598Eh, memory block size is  232 KiB
~-

[Oliver]

That works great. But i have two suggestions:

1. I would rename it from LINFO to FILEINFO. This is more meaningful in my opinion.
2. It should have a help option like discussed in the other thread about a general help for all extension commands.

-linfo help
... ; usage information is printed.
-

or as an alternative approach if you make the general help a part of the ext command:

-ext help linfo
... ; usage information about linfo.eld is printed and read from linfo.eld
-

[E. C. Masloch]

I would rename it from LINFO to FILEINFO. This is more meaningful in my opinion.

I think it displays information specifically about the L-command program load file, as specified by the N/K commands. I think FILEINFO could be mistaken as being more generic about what "files" it means, whereas LINFO is somewhat clearer that it is related to the L command.

Help will be added to the ELD.

[Oliver]

How about calling it LFINFO for Load File Info?
Or DINFO, for Debuggee Info.

Help will be added to the ELD.

Thanks

[E. C. Masloch]

However, linfo help won't show the help. ELD help pages are always transient (only available for oneshot operation or if read by list.eld), never installed residently. So you will have to do with ext linfo.eld help. Oh, just noticed it does have a transient help page already, although it is missing some of the features.

[Oliver]

ELD help pages are always transient (only available for oneshot operation or if read by list.eld), never installed residently.

Yes, that's what I assumed. The most important thing as of now would be that help can be accessed in a consistent way everywhere. And looks as uniform as possible.