Re: [hatari-devel] Little asm question

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On keskiviikko 20 helmikuu 2013, Eero Tamminen wrote:
> On keskiviikko 20 helmikuu 2013, Miro Kropáček wrote:
> > > Eero provided a python based symbol converter which processes Devpac
> > > listing files, providing the listing has been configured to append
> > > the symbol table at the end.
> > 
> > This is really painful. Isn't possible to do it on runtime?
> 
> Sure, set up breakpoints for doing the loading and script that.

Because basepage is invalid[1] until desktop is up, one unfortunately
cannot just set breakpoints for program startup like this:
	$ echo "symbols program.sym text" > load-symbols.ini
	$ echo "b pc = text :file load-symbols.ini" > debug.ini
	$ hatari --parse debug.ini

You need to invoke debugger after desktop is up and load debug.ini
manually in the debugger:
	> parse debug.ini

The main point of using debugger script is that you can put whatever
stuff to them you want to, and their file names are TAB completed,
so it's faster than typing the commands by hand.


[1] The main problem is that you cannot detect well whether basepage
    is invalid, points to TOS stuff, or to a user program, the pointer
    to basepage seems to change during TOS bootup somewhat "randomly",
	depending which TOS version you're using, is MiNT running etc.

	You can check beginning of src/debug/debugInfo.c on how the validity
	of basepage is checked.


NOTE: if you use some other way to trigger breakpoint actions than
basepage variables (text, data, bss), they CAN be set up at Hatari
startup.

You could for example use an illegal opcode in your sources to
invoke debugger breakpoint actions.  As an example, this injects
illegal opcode $cf4f to VBCC compiled C-code:
	  __asm("\tdc.w $cf4f\n");

You could then have in your debugger startup script something
like this:
	b (pc).w=$cf4f :file load-symbols.ini

Illegal opcodes are a handy way to insert breaks into your C-code. :-)


	- Eero