The state of source level debugging

Other misc things
Post Reply
tstih
New member
Posts: 2
Joined: Sun Oct 30, 2016 9:13 am

The state of source level debugging

Post by tstih »

I was just wondering if we can put on a table everything we collectively know about source level debugging for ZX Spectrum to get an overview of current technology. After a short google search here is what I found out.

1. Debugging Info files

a) SDCC, which is now also an integral part of z88dk, produces files called CDB. These C debug files are supposed to contain sufficient information for symbolic, source level debugging (i.e. modern debugging with breakpoints, where you can see C source code, and examine variables). Somewhere it says that CDB for 8051 is sufficient for source level debugging, but CDB produced for Z80 targets is not. Anyone knows more?

b) z80sim can do symbolic debugging of C code but requires DBG file which is supposed to be created by a tool called MakeDBG. No such tool has ever been found. I checked the z80sim code and it indeed tries to load .DBG file and C source code and symbols from it. So it does look like a promising start. Anyone knows more?

2. GDB for Z80 (rejected)
GDB for Z80 only talks assembler, can?t read symbolic files from known z80 compilers, and can?t interpret stack frames. The effort to add all three seems to be horrific due to the steep learning curve of GDB development. I successfully ported GDB stub (a small Z80 program that enables remote debugging) to ZX Spectrum and was able to do remote debugging of assembler using Interface 1 and serial comms, but the result was less than impressive. I only achieved what everyone can do in FUSE debugger for years.
I described it all here http://wischner.blogspot.co.uk/search/label/zx spectrum
To debug, you need to replace the original Sinclair ROM. For electronically-non-literates this is a daunting task.

3. Debugger
There is a debugger folder in SDCC! And it does contains GDB compatible (commands) debugger for 8051 that supposedly can read CDB files!! But no Z80 support. It is, however, fairly small and could be used as a starting point to develop a real debugger for Z80.

4. Emulation technology
A Russian ZX Spectrum emulator, written in C# can now ?talk GDB protocol? via TCP/IP. So it is possible to use GNU debugger to connect to it directly, with known limitations from point (2). But more importantly:
- The simple C# protocol (<500 lines of code) implementation is a good starting point to implement GDB protocol in other emulators.
- A potential simpler debugger (than GDB which requires monumental effort to port) could use this protocol and combine it with reading symbolic info from CDB files. Such ?GDB commands compatible? debugger could then be used from IDE environments as a GDB replacement.

5. z88dk
Current state of z88dk (beyond inclusion of SDCC) on debugging is not known. But as it does implement relocation (needed by the debugger) it seems like the only candidate to integrate with the debugger.

THE CUNNING PLAN
================
Here?s the cunning plan. If we can:
- get full relocation support by z88dk (we don?t need a self-relocating executable but a real relocation table, written to external file at compile time), no rocket science,
- introduce or extend symbolic debugging info files for SDCC / z88dk (CDBs or something else, just not too complex),
- write or obtain a parser to read these symbolic debugging files,
- refactor the existing GDB stub code (minimize it to a few hundred bytes!!!) which already implements everything required on a real Spectrum (i.e. breakpoints, registers,?), and somehow ?steal? i.e. rewire one RST call to our debugger from Sinclair ROM (anyone knows how we could do that in ROM without the environment noticing, it seems like Basic uses all of them?),
- as an alternative add the protocol to existing (two most popular) emulators,
- and write a command level compatible gdb shell that combines these all.
Then we?ve got ourself a source level debugging.
Stefan123
Member
Posts: 85
Joined: Fri Oct 21, 2016 7:57 am

Post by Stefan123 »

That sounds like an excellent initiative! :)
stefano
Well known member
Posts: 1695
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

I'm afraid it can be a complex task, on both z88dk and sdcc the source code is always compiled into asm, which in turn is optimized in several steps, so the linker/ assembler has no direct connections to the original C source. An interesting first step could be to find a way to pass the label names to the Emulators for their existing debugger, though.
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

stefano wrote:I'm afraid it can be a complex task, on both z88dk and sdcc the source code is always compiled into asm, which in turn is optimized in several steps, so the linker/ assembler has no direct connections to the original C source. An interesting first step could be to find a way to pass the label names to the Emulators for their existing debugger, though.
sdcc can produce debugging output for ucsim but I'm not sure how useful it is for non-8051 targets. The author of ucsim is active and is currently updating it to support a few other processors within sdcc.

I tried comparing what sdcc generated to what zsdcc generates at the asm level:

<code>
#include <stdio.h>

unsigned char buf[100];

void main(void)
{
sprintf(buf, "Hello World");
}
</code>

sdcc -mz80 -S test.c --debug
zcc +embedded -vn -a -clib=sdcc_iy test.c --debug

Both have symbols defined that point to variables in ram but those symbols only seem to carry information about location and nothing about the type. sdcc is adding more symbols to mark the start of functions. Why they don't appear in the version produced by zcc I don't know -- generating the asm follows the exact same steps in both compiles, aside from the translation step. sdcc also seems to produce an adb file which is a summary of those debug symbols produced in the asm listing and new symbols that describe all the functions defined in stdio.h. So it appears that maybe asz80 gets a second look at the .asm file when --debug is used.

If you compile to object file:

sdcc -mz80 test.c --debug

sdcc's linker will also produce the cdb file from the adb file. This seems to be the adb file with a list of resolved absolute addresses following. We can't compile the --debug asm file using zcc because the asz80->zilog translator is not handling the special debug symbols with $ in them so z80asm will complain about a syntax error. However we already know it won't generate a cdb file. In the current build of zsdcc we've fixed the rodata section bug in sdcc and from that I can see that the debug symbols are being generated in the wrong place just after a section is closed by activating the code section and just before the rodata section is opened.

With z80asm you can get the map file to learn absolute locations of symbols. It can also generate a separate .reloc file for runtime binary relocation. If you add "--c-code-in-asm" you can also get C code as comments embedded in the asm file although as stef said it could be this embedded C code is sometimes slightly misplaced due to optimizations. Another tool could probably combine all these things into whatever ucsim needs.

If ucsim is good enough then it should be targeted otherwise you'll have to come up with a list of requirements from the compilers and linker. You can get whatever you want out of the linker now but maybe harder is getting good information out of the compiler. In z88dk there will be three compilers soon :- sccz80 which doesn't generate debug info, sdcc which generates adb/cdb and clang/llvm which will be acting as a front-end to sdcc so nothing useful will come out of that for debugging although maybe you can get some source-related information out of llvm that could be used in debugging with a considerable amount of effort.
somehow ?steal? i.e. rewire one RST call to our debugger from Sinclair ROM (anyone knows how we could do that in ROM without the environment noticing, it seems like Basic uses all of them?),
I think the best RSTs to grab would be RST 0 (reset) and RST 66h (nmi, probably best choice). Nothing will work on an unmodified spectrum (except for +3 which can page ram into the bottom 16k) but it could be made to work in an emulator. On real spectrums there are also devices that can place ram in the bottom 16k so this sort of thing could be supported on those machines too.
Post Reply