.lis file address field

[maziac]

Hi,

sorry to open a bug for this but there is no discussion forum.

I'm the author of DeZog (Z80 debugger) which parses the z88dk list file to get file/line number associations to the asm source files. A user brought up that the z88dk-z80asm list file format has changed that's why I raised the other issue about 4 and 6 digits.

Anyhow I have a question:

The address used in the .lis file is difficult to parse as it is not the real physical address but something else.

Would it be possible to use the physical address instead in that field. Or could you explain what the address field really shows?

Here is a short snippet:

    13                              ORG 0x8000
    14
    15                          label1:
    16   0000 00                nop
    17
    18   0001 3e05            label2:   ld a,5

Here the 0000 is actually the physical address 0x8000.

[suborb]

It's not directly a solution, but adding -debug and digging into the .sym files might solve the problem.

From something I was testing:

__ASM_LINE_221__2fUsers_2fdom_2fz88dk_2flib_2fconfig_2f_2e_2e_2f_2e_2e_2f_2flib_2ftarget_2fcpc_2fclassic_2fcpc_5fcrt0_2easm = $175B ; addr, local, , cpc_crt0, bss_crt, /Users/dom/z88dk/lib/config/../..//lib/target/cpc/classic/cpc_crt0.asm:221

[maziac]

In my tests the sym file did not contain the physical address either:

label1                          = $0000 ; addr, local, , , , main.asm:15
label2                          = $0001 ; addr, local, , , , main.asm:18

The .map does, but that's only for labels. I need the information per line with an opcode. I have a solution but that is not nice and also only 99% certain, but I would rather use a simpler, less error prone, parsing algorithm.

[suborb]

In my tests the symptoms file did not contain the physical address either:

Sorry, I meant the .map file. If you assemble with -debug then it will insert a label corresponding to each line in the source file.

Thus, you can read the .map file to get the address, then go to the source file to get the opcode/source assembly.

[maziac]

OK, I see. Good hint. That would mean in total I would need to analyze 2 files:

1. The sym file for the physical address and file/line <-> address association and for the labels
2. The .lis file for the EQU labels (or can I get the EQUs somewhere else?) and the size of the data/opcode for a specific line

Seems feasible. Would be nice if I could just read the map file?

Is it possible to obtain the data/opcode size and the equipment label values somewhere?

And do you know if this debug option worked already with the 1.x version or when this was introduced?

What is the other info ?

data2                           = $8016 ; addr, local, , main, , main.asm:50
__ASM_LINE_50_main_2easm        = $8016 ; addr, local, , main, , main.asm:50

E.g. adder, local, , main

[suborb]

For the ticks debugger we extract everything from the .map file - the parser is here: https://github.com/z88dk/z88dk/blob/master/src/ticks/syms.c

I'm not sure when it was added (probably in the past 18 months or so).

• addr/const - label or defc
• local/public = not exported/exported
• [empty bit] = not sure
• main = module name
• [empty bit] = section name
• main.asm:50 = file and line where defined

I imagine @pauloscustodio can correct/fill int he blanks

I don't think size of the opcode is in the file, though I guess it could be inferred by searching for the next __ASM_LINE_ label?

[maziac]

Is defc the same as EQU ?

At least for labels defined as EQU like

label_equ1:     equ 100

I can't find them in the map file, even with '-debug'.

[suborb]

I can only reproduce that if the EQU is neither used nor exported from a file which is a little oddity, but doesn't seem like it should cause any trouble.

[maziac]

OK, I see. The EQU need to be used, then it appears in the map file.

I will try to change my parser to use the map file instead of the lis file. Seems to be really easier.

Thanks for the help.

[desertkun]

Random question, are you aware that z88dk-ticks and z88dk-gdb now support mi2 protocol and can be debuggable in Visual Studio Code?

https://github.com/z88dk/z88dk/pull/2025

I didn't do a wiki but here's a Facebook post about it

https://www.facebook.com/groups/Z88dkZXSpectrumUserGroup/permalink/1046227266285228/

[maziac]

No, I wasn't aware of that. I'll give it a try. If it works out fine I could drop support for z88dk for DeZog.

[maziac]

@desertkun Do you maybe have a readily available test setup/program with description? I don't have an idea how to set this up- E.g. which vscode gdb extension are you using? How is the general setup: vscode <-> gdb (z88dk) <-> emulator ...

[desertkun]

@maziac I've pushed an example repository https://github.com/speccytools/z88dk-gdb-vscode-test Feel free to make a fork it doesn't work for you right away, and submit a pull request.

[maziac]

Thanks. But... what vscode extension is used?

[maziac]

Here is how far I got:

1. the vscode executable is probably "Native Debug" by WebFreak. At least I was able to start the z88dk-gdb and it was able to connect to mame.
2. The mame command line i used was: ./mame spectrum -resolution 640x480 -window -debug -debugger gdbstub -debugger_port 1337
3. To build the program I tried make/make:

   > z88dk-gdb-ide-test % cmake .        
   -- The C compiler identification is AppleClang 14.0.0.14000029
   -- Detecting C compiler ABI info
   -- Detecting C compiler ABI info - done
   -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
   -- Detecting C compile features
   -- Detecting C compile features - done
   -- Configuring done
   -- Generating done
   -- Build files have been written to: /Volumes/SDDPCIE2TB/Projects/Z80/asm/dezog_issues/desertkun/z88dk-gdb-ide-test
   bob@macmini z88dk-gdb-ide-test % make
   [ 50%] Building C object CMakeFiles/idetest.dir/main.c.o
   clang: warning: argument unused during compilation: '-debug' [-Wunused-command-line-argument]
   [100%] Linking C executable idetest
   ld: library not found for -lndos
   clang: error: linker command failed with exit code 1 (use -v to see invocation)
   make[2]: *** [idetest] Error 1
   make[1]: *** [CMakeFiles/idetest.dir/all] Error 2
   make: *** [all] Error 2
   > z88dk-gdb-ide-test % 

But as you can see the make did not succeed.

Could you simply just the the project including binaries, sources and map file. At the moment I'm not interested in compiling/building issues, I just would like to debug.

[desertkun]

cmake .

That's because you're not doing project generation from IDEs and doing it on your own, so cmake chosen default compiler, cc. See this wiki article on how to use cmake manually within z88dk, it's relatively new feature.

VSCode does that for you in settings.json https://github.com/speccytools/z88dk-gdb-ide-test/blob/master/.vscode/settings.json

I've made instructions on how to do it from CLI here https://github.com/speccytools/z88dk-gdb-ide-test/blob/master/Readme.md#building-and-debugging-on-cli

[maziac]

Couldn't you simply zip your project together with the binaries and map files and attach it here. Would make my life easier.

[desertkun]

Can do, see build/ subfolder. Hope mame works for you I haven't tested it for a while, my fork of Fuse with gdbstub on https://speccytools.org should work too.

z88dk-gdb-ide-test.zip

--

You also can build a +test platform and run it in z88dk-ticks, which is a gdb and terminal-only emulator in one package. Here's pre-built +test platform, which won't work on speccy, but would work on ticks, just go into build folder and do z88dk-ticks -d -x idetest.map idetest.bin:

z88dk-gdb-ide-test.zip