Hello again!
My quick-hack has now extended over 2.5 months but finally I think I can show some useful results!
I made some code which demostrates remote debugging on the z88dk/test/machine platform.
I made alterations to 10-12 different files and added a few of my own!
It can currently only set one breakpoint and cannot read/alter variables!
Look at the screen dump: http://www.algonet.se/~mimarob/z80dbg.jpg
Any interest to help me integrate towards 1.9?
No changes in the compiler (yet) but I added a few things in the test/machine section.
/Erik
Simple debugger in 1.9???
Hmm, lets see...
I made some additions to the test_crt0.asm, this could of course be its
own "target" like debugtest_crt0.asm instead.
I added some code to save and restore registers after a breakpoint.
I made it use rst 10, but this is in no way written in stone!
In the test/machine/main.c file I added a bunch of new options needed to be
able to both do stdin/stdout and talk to the debugger via a socket
interface (mysock.h and mysock.c). There is also a possibility to
do assembler debugging. It should not interfere with ordinary use
of the test machine. Also another command (in cmds.h) has been added in the
defb $ED,$FE trap. This enables the machine to exchange hex strings via the
debug socket. This corresponds to a serial line with some code on a real live
target.
I also added something to Z80.c Z80.h & Debug.c
I made the disassembly routine public and also added an InstrZ80 call to make
it possible to execute N instructions (used in the assembler monitor)
Then there is the debugger.c file which interprets the serial line
commands (such as set breakpoint, get/set registers alter memory etc.)
This is currently linked in with the source (hello.c) but should be
build with the libraries.
Finally there are a bunch of scripts used to get symbols out of .map
file and also recompile on-the-fly to figure out at which assembler address
to set the next breakpoint. Don't know how future safe these will be though
The intelligence is built into a tcl/expect script which talks to the
primitive debugger on the target.
In order to port this to a real platform, the programmer should use a drop-in
replacement for the "machine" binary. The tcl/expect debugger will connect
to that instead and start talking hex strings back and forth, so the programmer
will need to make the serial line protocol work from the machine process to
the serial port (i.e. write some code instead of using the defd $ED,$FE).
If one is keen to save bytes of course the debugger.c command interpreter
could be written in assembler instead. There are also a set of routines in the
beginning of debugger.c that might need adapting to a specific target, maybe
these should go into a separate file as well?
I have started on some more code to read variables, but in order
to interpret and present them correctly to the user, one has to either get
the z88dk compiler to output its type (typeof operator??) or obtain that
through an external parser of some kind (lex/yacc, antlr or similar).
So to finalize, right now there are mods to test/machine main.c Z80.c/h
Debug.c, cmds.h and test_crt0.asm. mysock.h/c are added.
In order to make test_crt0.asm compile you also need debugger.c
All of this should stay passive and not interfere unless enabled!
Socket stuff seems to build under linux and cygwin but I don't know about
native Windows, could use a null plugin if worst comes to worst.
Tell me if you want me to dump the files somewhere!
Cheers /Erik
I made some additions to the test_crt0.asm, this could of course be its
own "target" like debugtest_crt0.asm instead.
I added some code to save and restore registers after a breakpoint.
I made it use rst 10, but this is in no way written in stone!
In the test/machine/main.c file I added a bunch of new options needed to be
able to both do stdin/stdout and talk to the debugger via a socket
interface (mysock.h and mysock.c). There is also a possibility to
do assembler debugging. It should not interfere with ordinary use
of the test machine. Also another command (in cmds.h) has been added in the
defb $ED,$FE trap. This enables the machine to exchange hex strings via the
debug socket. This corresponds to a serial line with some code on a real live
target.
I also added something to Z80.c Z80.h & Debug.c
I made the disassembly routine public and also added an InstrZ80 call to make
it possible to execute N instructions (used in the assembler monitor)
Then there is the debugger.c file which interprets the serial line
commands (such as set breakpoint, get/set registers alter memory etc.)
This is currently linked in with the source (hello.c) but should be
build with the libraries.
Finally there are a bunch of scripts used to get symbols out of .map
file and also recompile on-the-fly to figure out at which assembler address
to set the next breakpoint. Don't know how future safe these will be though
The intelligence is built into a tcl/expect script which talks to the
primitive debugger on the target.
In order to port this to a real platform, the programmer should use a drop-in
replacement for the "machine" binary. The tcl/expect debugger will connect
to that instead and start talking hex strings back and forth, so the programmer
will need to make the serial line protocol work from the machine process to
the serial port (i.e. write some code instead of using the defd $ED,$FE).
If one is keen to save bytes of course the debugger.c command interpreter
could be written in assembler instead. There are also a set of routines in the
beginning of debugger.c that might need adapting to a specific target, maybe
these should go into a separate file as well?
I have started on some more code to read variables, but in order
to interpret and present them correctly to the user, one has to either get
the z88dk compiler to output its type (typeof operator??) or obtain that
through an external parser of some kind (lex/yacc, antlr or similar).
So to finalize, right now there are mods to test/machine main.c Z80.c/h
Debug.c, cmds.h and test_crt0.asm. mysock.h/c are added.
In order to make test_crt0.asm compile you also need debugger.c
All of this should stay passive and not interfere unless enabled!
Socket stuff seems to build under linux and cygwin but I don't know about
native Windows, could use a null plugin if worst comes to worst.
Tell me if you want me to dump the files somewhere!
Cheers /Erik
This is off-topic, but I sent here a trick to enable pure C assertions (http://www.z88dk.org/forum/viewtopic.php?id=2775). This works conjointly with WinAPE Amstrad CPC emulator.
Hello again!
Today I put up a snapshot tar-gz at http://www.algonet.se/~mimarob/z88dk/
It compiled and ran today (2008-06-04 8:30 GMT) towards a fresh checkout of the main CVS!
Inside is a (dangerous!) script called patcha_z88dk that will modify /home/$USER/z88dk and build the z88dk simulator + the debugger stuff in the z80dbg directory.
Don't keep valuable work in ~/z88dk when doing this!!!!
It is best to use a fresh checkout or unpacked release when doing this to make sure everything is rebuilt!
Also don't forget to set your PATH to ~/z88dk/bin or you can get mysterious errors...
You'll need tcl/expect installed and probably some more packages I forgot about!
In the script patcha_z88dk is a series of "cp" commands so you can see exactly which files I modified / added!
When done you should have a "machine" binary with a symlink. It should be compatible with the current machine
but contain a few hidden options.
The "hitnrun.exp" is the actual debugger, it will give you a DBG> prompt from which to issue commands.
You also need X-windows working, the debugger will pop up an extra window for the I/O of the machine via the "xterm" command!
Happy testing, I know there must be tons of bugs in this experimental version :-/
Today I put up a snapshot tar-gz at http://www.algonet.se/~mimarob/z88dk/
It compiled and ran today (2008-06-04 8:30 GMT) towards a fresh checkout of the main CVS!
Inside is a (dangerous!) script called patcha_z88dk that will modify /home/$USER/z88dk and build the z88dk simulator + the debugger stuff in the z80dbg directory.
Don't keep valuable work in ~/z88dk when doing this!!!!
It is best to use a fresh checkout or unpacked release when doing this to make sure everything is rebuilt!
Also don't forget to set your PATH to ~/z88dk/bin or you can get mysterious errors...
You'll need tcl/expect installed and probably some more packages I forgot about!
In the script patcha_z88dk is a series of "cp" commands so you can see exactly which files I modified / added!
When done you should have a "machine" binary with a symlink. It should be compatible with the current machine
but contain a few hidden options.
The "hitnrun.exp" is the actual debugger, it will give you a DBG> prompt from which to issue commands.
You also need X-windows working, the debugger will pop up an extra window for the I/O of the machine via the "xterm" command!
Happy testing, I know there must be tons of bugs in this experimental version :-/
Last edited by mimarob on Wed Jun 04, 2008 11:37 am, edited 1 time in total.
I'm guessing the url is actually: http://www.algonet.se/~mimarob/z88dk/
I'll take a proper look at it later, BTW you're looking for SOREUSEADDR
I'll take a proper look at it later, BTW you're looking for SOREUSEADDR