wdw register state not working properly

[rdos314]

If the registers are already shown, only the first column can be highlighted by clicking on it (cursor keys seems to work though). When selecting registers from the menu, the debugger crashes.

[rdos314]

There are multiple problems with the debugger. The fault that is triggered when register context is selected (or the window is clicked) is due to line.length having an undefined value in wndcurr.c, WndSetPoint(). This is because wndmeth.c is not initializing this field. However, when this is initialized to zero, only registers in the first column can be changed with the mouse, so the real problem is hidden by the initialization.

[rdos314]

Another issue is that "Source code not found" seems to affect RDOS drivers. It seems like finding the source is done in dbgwinsp.c, WndSrcInspect(). At least, the error message is shown there.

[rdos314]

This seems to be an issue with DLLs too. The dwarf/dr/c/drline.c file, procedure DRWalkLFiles method seems to be at the heart of this problem. For exe sources, it returns the correct pathname, but not for DLLs or RDOS device drivers. A problem with debugging this is that drline.c is in the dwarf.dll, so I cannot debug it at source level.

More checks seems to reveal that it is only loaded DLLs, and not automatically imported that are not showing source information. The RDOS device drivers are also loaded on access.

[jmalak]

I will review.
There are other changes related to DIP/MAP/TRAP loading and source file lookup.
Also in OMF files there is a change related to correct passing of source files in a module (multiple THEADR entries).
Maybe I broken something.

[jmalak]

@rdos314
Please, what compiler and linker options you used for RDOS drivers which have issue with source file lookup?

[rdos314]

I can see with wdump that the full path of the filename is present in DW_AT_name in the symbol file. The symbol file is read correctly too since line numbers are shown. It's just the source that is not displayed.

I compiled dwarf for debug and it appears the same problem is present with all the dr*.c files, while the other files in the dll works as they should. Since it is in drline.c file that the problems seems to be for RDOS drivers, it's a bit hard to debug.

[rdos314]

Trace:
OpenSrcFile in dbgsrc.c calls DIPCueFile
DIPCueFile in dipman.c calls CueFile
CueFile in dfcue.c calls DRWalkLFiles
DRWalkLFiles is in drline.c and has no source

The wlk.res variable contains the full source path when it works, but the name of the module when it doesn't work.

[rdos314]

Assembler switches: -mf -6r -fpi87 -d1 -w4 -e25 -zq
C switches: -w4 -e25 -zp1 -zq -otexan -of+ -s -oi -d2 -bm -fpi87 -zdp -zff -zu -3r -bt=rdosdev -fo=xxx -mc
Linker switches: name vfs d all sys rdosdev op codesel=0x7C0 op datasel=0x7C8 op m op maplines op v op maxe=25 op symf

[jmalak]

The main change is in multiple THEADR records, if exists only one then it should works as before. If there are two records then first is module name used by linker and librarian and should be ignored by debugger and second record is true source file name only. Next THEADR record change source file name only. It is not used as module name, module name is always defined by first THEADR record. -d1 option and above should generate OMF modules with two THEADR records on the begining and second one should contain full source file name. Try to check.

[rdos314]

When I switch debugger version all the way back to 2021, the same bug remains. When I rebuild the device driver with a build from 2023-12-29 the device driver source is ok and the bug disappears.

[jmalak]

Then it looks like a bug in debug info processing for source file name or may be more bugs for different versions.
I must review/test/fix it.

[rdos314]

I also note that a device driver where the first module is a C file works for the first file, but all the rest show ups without source code.

I think for dr*.c, there might be a bug that doesn't compile those with source information even when OWDEBUGBUILD is set to 1. I note that these files will show no local variables, although the line number information still appears to be correct.

[jmalak]

In debugger is involved more projects that if you recompile for debug only single project then only some files have debug info available. Definitely it is issue with source file name lookup, may be another errors too.

[rdos314]

I have gotten close to the cause now. It's cu_tag in the modinfo structure that is incorrect. When the source is found, this field contains the full pathname, while for newly linked device drivers, it contains this junk in hex: 02 83 09 00. Going to the source of this information, the ModFill function in dfmod.c gets this junk when it calls DRGetCompileUnitTag. Here the data looks like this in hex: 02 83 09 00 00 "E:\rdos\kernel\fs\dev\devfile.c" 00. IOW, the position for finding the source filename is five bytes off, and instead returns junk.

[jmalak]

It is strange.
It could be a problem in Dwarf writer functions which generate Dwarf data.
Could you check if affected is only C source or also ASM source?

[rdos314]

It appears that for ASM source, the problem is that the sym-file does not contain the full path of the source files. Checked C files a bit more, they contain the full source path, and at least the ModFill function also decodes it correctly. So, the main problem seems to be that ASM source no longer registers the full path of source files. Checked an application too, and it's is the same problem. The full path of ASM source is not in the symbol file. Actually, I think this problem can be connected to source that is not compiled with symbols too. I have a clib that is not compiled for debug, and all the files from it, both ASM and C lack the full path for source files. Which is why I initially couldn't debug part of dwarf.dll. The linker needs to register the full path of all source files, regardless of settings for debug-info, otherwise, the debugger will show that source is not available instead of the assembly code.

A very simple driver source in ASM (32-bit RDOS device driver):
`
.386

code SEGMENT byte public use32 'CODE'

assume cs:code

test_name DB 'Test func', 0

test_func Proc far
nop
ret
test_func Endp

init PROC far
mov eax,cs
mov ds,eax
mov es,eax
;
mov esi,OFFSET test_func
mov edi,OFFSET test_name
xor dx,dx
mov ax,442
db 3Eh
db 67h
db 9Ah
dd 3
dw 2
ret
init ENDP

code ENDS

END init

`

With the old compiler & linker wdump shows this info:

Offset: 00000000 Length: 00000051 Version: 0002 Abbrev: 00000000 Address Size 04
Offset: 0000000B Code: 00000001
DW_TAG_compile_unit
DW_AT_name "C:\rdos\kernel\test\test.asm"
DW_AT_producer "V1.0 WATCOM"
DW_AT_stmt_list 00000000
Offset: 00000039 Code: 00000003
DW_TAG_label
DW_AT_low_pc 0000000A
DW_AT_external False
DW_AT_name "test_func"
Offset: 00000049 Code: 00000003
DW_TAG_label
DW_AT_low_pc 0000000C
DW_AT_external False
DW_AT_name "init"
Offset: 00000054 Code: 00000000

With the current assembler & linker it looks like this:

Offset: 00000000 Length: 00000039 Version: 0002 Abbrev: 00000000 Address Size 04
Offset: 0000000B Code: 00000001
DW_TAG_compile_unit
DW_AT_name "test"
DW_AT_producer "V1.0 WATCOM"
DW_AT_stmt_list 00000000
Offset: 00000021 Code: 00000003
DW_TAG_label
DW_AT_low_pc 0000000A
DW_AT_external False
DW_AT_name "test_func"
Offset: 00000031 Code: 00000003
DW_TAG_label
DW_AT_low_pc 0000000C
DW_AT_external False
DW_AT_name "init"
Offset: 0000003C Code: 00000000