Output to debugger console?

[simonsunnyboy]

Is it possible to write to the Hatari debugger console from any Atari application somehow?

I'm thinking of debug texts. My idea is to write a special assert() routine that outputs its file, line, condition texts to the debugger console instead of any Atari device and then halts into the debugger.

So that I basically get something like this:

Code: Select all

Assertion failed
File: xyz.c Line: 333  Condition: (input < 10)

CPU=$e06936, VBL=911, FrameCycles=140, HBL=0, LineCycles=140, DSP=N/A
$00e06936 : 3039 0000 1688                     move.w    $1688,d0
>

[mfro]

Hatari understands the natfeats APIs when started with "--natfeats true".

You are then able to call code to output anything to the hatari console or call the debugger. Example code is here: https://github.com/libretro/hatari/tree ... s/natfeats

[Eero Tamminen]

And the same code in Hatari repository: http://hg.tuxfamily.org/mercurialroot/h ... s/natfeats

[simonsunnyboy]

Perfect, that was the info I was looking for! Thank you both!

[simonsunnyboy]

Hatari understands the natfeats APIs when started with "--natfeats true".

You are then able to call code to output anything to the hatari console or call the debugger. Example code is here: https://github.com/libretro/hatari/tree ... s/natfeats

While browsing the source, I noticed int and long are used where I prefer stdint.h.
Is int 16 or 32 bit in these sources?

[Eero Tamminen]

That depends on compiler and compiler options. By default, with AHCC it's 16 bit, with GCC it's 32 bit.

[simonsunnyboy]

So Hatari itself does not care?

*EDIT* Nevermind, analyzing the assembly interface stub told me, it is always long on return.

[simonsunnyboy]

I added this to my latest project and nf_print() works good.
However nf_debugger() does not activate the debugger. What am i missing here?

nfid_debugger is non-zero.

Code: Select all

> m _nfid_debugger
00035022: 00 60 00 00 00 01 00 00 00 01 00 00 00 00 00 03   .`..............

[Eero Tamminen]

Do you see NF_DEBUGGER() output if you use "--natfeats on --trace natfeats"?

Are you using Hatari build with WinUAE or oldUAE CPU core? Some specific release or latest from Mercurial?

(It's possible there's been some change in CPU core SPCFLAG_DEBUGGER flag handling.)

[simonsunnyboy]

Hatari is about 1 week old, compiled from hg with WinUAE CPU:

Code: Select all

Hatari v1.9.0-devel (Apr 10 2016) (WinUAE CPU core), compiled on:  Apr 10 2016, 09:42:37

Output with --trace natfeats is something like this:

Code: Select all

<...>
NF_STDERR(0xd7b2)
--> Debugger entry 
NF_DEBUGGER()
NF_STDERR(0x1ef5f)
C:\COMMANDO\COMMANDO.PRGNF_STDERR(0xd7af)

NF_STDERR(0x2d4ea)
Exolon (Klapauzius);C:\EXOLON.PRGNF_STDERR(0xd7af)

NF_STDERR(0xd7b2)
--> Debugger entry 
NF_DEBUGGER()
NF_STDERR(0x1f085)
C:\EXOLON.PRGNF_STDERR(0xd7af)

NF_STDERR(0x2d4ea)
NF_STDERR(0xd7af)

NF_STDERR(0xd7b2)
--> Debugger entry 
NF_DEBUGGER()

No debugger entry is happening.

[Eero Tamminen]

Does the attached patch make NF_DEBUGGER work?

(I'm amazed if current code in Hatari ever actually invoked debugger although that code is already from end of 2013. All it did was just make CPU core to call debugger check, not trigger the check that actually stops the execution there.)

[simonsunnyboy]

I had some troubles getting the patch applied (hg import --no-commit <patchfile>)

But I have success now, it drops me into the debugger as desired. All the points in my log where desired jumps into the debugger, not unwanted ones.

I hope this patch is going to be upstreamed into the hg repository?

I also have an idea how to exploit those features. I'll add a logging buffer which can be streamed with a forced breakpoint into the debugger and/or assert. Let's see how good this will help.

It already feels way more powerful than running MonST or Bugaboo inside Hatari

Thank you for support!

[Eero Tamminen]

Thanks for testing. I pushed the fix to Hatari repo, along with 'n' (next) command support for running loops through on their last dbcc instruction.

[simonsunnyboy]

Now I have written a very basic debugging environment that exploits the Hatari native features for output

i have:
- variable traces (needs Atari-side code with mapping)
- assertions with useful debug information
- basic print and breakpoint support

Planned:
- nicer coredump output
- exceptions handlers so that 2,3, or 4 bombs call the debugger

The whole thing is for gcc without MintLib (hence custom string functions) but you'll get the point:

Public header:

Code: Select all

/************************************************************
 * Atari ST Harddisk Menu by Paradize                       *
 ************************************************************
 * @file natfeats_debug.h
 * @author Simon Sunnyboy / Paradize <marndt@asmsoftware.de>
 * @copyright Paradize http://paradize.atari.org/
 ************************************************************
 * @brief API for debugging with Hatari native features
 */

#ifndef NATFEATS_DEBUG_H
	#define NATFEATS_DEBUG_H

	#include <stdint.h>

	typedef enum
	{
		CD_I8,
		CD_U8,
		CD_I16,
		CD_U16,
		CD_I32,
		CD_U32,
		CD_BOOL,
		CD_STRING
	} Coredump_id_e;

	void DBG_AddTrace(const char * varname, Coredump_id_e id, void * dptr);
	void DBG_ClearTrace(void);

	#ifdef USE_NATFEATS



		void DBG_Init(void);
		void DBG_Print(const char *str);
		void DBG_Breakpoint(void);
		void DBG_Coredump(void);

		void DBG_assert(const char *cond, const char * filename, const uint16_t line);

		#define assert(x) (((x) == 0) ? DBG_assert(#x, __FILE__, __LINE__):(void)0)


	#else

		#define DBG_Coredump()    ((void)0)
		#define DBG_Init()        ((void)0)
		#define DBG_Print(x)      ((void)0)
		#define DBG_Breakpoint()  ((void)0)

		#define assert(x)      ((void)0)

	#endif
#endif // NATFEATS_DEBUG_H

Main implementation (needs Eero's Natfeats access assembly source):

Code: Select all

/************************************************************
 * Atari ST Harddisk Menu by Paradize                       *
 ************************************************************
 * @file natfeats_debug.c
 * @author Simon Sunnyboy / Paradize <marndt@asmsoftware.de>
 * @author Eero Tamminen (Hatari natfeats access API)
 * @copyright Paradize http://paradize.atari.org/
 ************************************************************
 * @brief main() function and handling
 */

#include <stdint.h>
#include <stdbool.h>
#include <mint/osbind.h>

/* public interface */
#include "natfeats_debug.h"

#include "string_lib.h"

/* internal ASM helper interface for natfeats.c */
extern int32_t nf_id(const char *);
/* it's best not to use this directly as arguments are untyped */
extern int32_t nf_call(int32_t ID, ...);
/* call only from Supervisor mode */
extern int16_t detect_nf(void);

#define COREDUMP_MAX_ENTRIES  50


typedef struct
{
	char           entry[20];   /**< variable name */
	Coredump_id_e  id;          /**< id tag to identify coredump entry */
	void           *dptr;       /**< pointer to data */
} Coredump_t;

static uint16_t coredump_nr_entries = 0;

Coredump_t coredump[COREDUMP_MAX_ENTRIES];

#define  NATFEATS_UNDETECTED   -1

/* NatFeats available & initialized */
static int16_t nf_ok = NATFEATS_UNDETECTED;

/* handles for NF features that may be used more frequently */
static int32_t nfid_print, nfid_debugger;

/* API documentation is in natfeats.h header */

static void nf_init(void)
{
	if(nf_ok == NATFEATS_UNDETECTED)
	{
		void *sup = (void*)Super(0);
		nf_ok = detect_nf();
		Super(sup);

		if (nf_ok) {
			/* initialize commonly used handles */
			nfid_print = nf_id("NF_STDERR");
			nfid_debugger = nf_id("NF_DEBUGGER");
		}
	}

	return;
}

void DBG_AddTrace(const char * varname, Coredump_id_e id, void * dptr)
{
	if(coredump_nr_entries < COREDUMP_MAX_ENTRIES)
	{
		StrCpy(coredump[coredump_nr_entries].entry, (char *)varname);
		coredump[coredump_nr_entries].id = id;
		coredump[coredump_nr_entries].dptr = dptr;
		coredump_nr_entries++;
	}
}

void DBG_ClearTrace(void)
{
	coredump_nr_entries = 0;
}

#ifdef USE_NATFEATS

	#pragma message(" -- debugging with native features enabled")

	static char numbers[10];

	static char * U32_ASCII(const uint32_t val)
	{
		uint16_t idx = 9;
		uint32_t tmp = val;

		numbers[9]='\0';

		do
		{
			idx--;
			numbers[idx] = '0' + (uint8_t)(tmp % 10);
			tmp /= 10;
		}
		while((tmp > 0)||(idx == 0));

		return &numbers[idx];
	}

	static char * I32_ASCII(const int32_t val)
	{
		uint16_t idx = 9;
		int32_t tmp = val;
		bool sign = false;

		if(tmp < 0)
		{
			sign = true;
			tmp = -val;
		}

		numbers[9]='\0';

		do
		{
			idx--;
			numbers[idx] = '0' + (uint8_t)(tmp % 10);
			tmp /= 10;
		}
		while((tmp > 0)||(idx == 1));

		if(sign == true)
		{
			idx--;
			numbers[idx] = '-';
		}

		return &numbers[idx];
	}

	void DBG_Coredump(void)
	{
		uint16_t idx = 0;
		DBG_Print("\r\n----   COREDUMP   ------------------------------------------------------------\r\n");
		while(idx < coredump_nr_entries)
		{
			DBG_Print(coredump[idx].entry);
			DBG_Print(" = ");

			switch(coredump[idx].id)
			{
			case CD_I8:
				{
					int8_t val = *(int8_t *)coredump[idx].dptr;
					DBG_Print(I32_ASCII(val));
				}
				break;
			case CD_I16:
				{
					int16_t val = *(int16_t *)coredump[idx].dptr;
					DBG_Print(I32_ASCII(val));
				}
				break;
			case CD_I32:
				{
					int32_t val = *(int32_t *)coredump[idx].dptr;
					DBG_Print(I32_ASCII(val));
				}
				break;
			case CD_U8:
				{
					uint8_t val = *(uint8_t *)coredump[idx].dptr;
					DBG_Print(U32_ASCII(val));
				}
				break;
			case CD_U16:
				{
					uint16_t val = *(uint16_t *)coredump[idx].dptr;
					DBG_Print(U32_ASCII(val));
				}
				break;
			case CD_U32:
				{
					uint32_t val = *(uint32_t *)coredump[idx].dptr;
					DBG_Print(U32_ASCII(val));
				}
				break;
			case CD_BOOL:
				{
					bool val = *(bool *)coredump[idx].dptr;
					if(val == true)
					{
						DBG_Print("TRUE");
					}
					else
					{
						DBG_Print("FALSE");
					}
				}
				break;
			case CD_STRING:
				{
					char * to_w = (char *)coredump[idx].dptr;
					DBG_Print(to_w);
				}
				break;
			default:
				DBG_Print("<undefined id>");
				break;
			}
			DBG_Print("\r\n");
			idx++;
		}


	}


	void DBG_Init(void)
	{
		nf_init();

	}

	void DBG_Print(const char *str)
	{
		nf_init();

		if (nfid_print)
		{
			(void)nf_call(nfid_print, str);
		}
	}

	void DBG_Breakpoint(void)
	{
		nf_init();

		if (nfid_debugger)
		{
			DBG_Print("\r\n----    DEBUGGER ENTRY    ---------------------------------------------------\r\n");
			(void)nf_call(nfid_debugger);
		}
	}

	void DBG_assert(const char *cond, const char * filename, const uint16_t line)
	{
		DBG_Print("\r\n----    ASSERTION FAILED    -------------------------------------------------\r\n");
		DBG_Print("Assertion failed: ");
		DBG_Print(cond);
		DBG_Print("\r\nFile: ");
		DBG_Print(filename);
		DBG_Print("\r\nLine: ");
		DBG_Print(U32_ASCII(line));
		DBG_Coredump();
		DBG_Breakpoint();
	}



#endif // USE_NATFEATS

The code:
- calls DBG_Init(9 once
- uses assert() like assert.h would be used
- DBG_AddTrace() to add variables to the coredump
- DBG_ClearTrace() to clear them (can be also used to dump locals if stack order is maintained
- DBG_Coredump(9 to force a nice output to the Hatari debugger window

Example code from my current project:

Code: Select all

static DB_state DB_ParseCSV(int32_t handle)
{
	DB_state st = DB_EMPTY;


	if(handle < 0)
	{
		return DB_GEMDOS_ERROR;
	}

	int32_t ch_read;

	DBG_AddTrace("ch_read", CD_I32, &ch_read);  // trace a local variable
	DBG_AddTrace("ProgDB_entries", CD_U16, &ProgDB_entries); // globals..
	DBG_AddTrace("linebuf",CD_STRING,linebuf);
	DBG_AddTrace("path prog 1",CD_STRING,ProgDB[0].pathname);
	DBG_AddTrace("prog 1",CD_STRING,ProgDB[0].progname);

	/* process ing loop with asserts etc omitted */

	DBG_Coredump();
	DBG_ClearTrace();   // we must clear the trace or the locals are messed up

	return st;
}

Inside the hatari window, it will look like this:

Code: Select all

----    ASSERTION FAILED    -------------------------------------------------
Assertion failed: <none>
File: /home/marndt/Projects/Atari/harddisk_menu/src/prog_database.c
Line: 170
----   COREDUMP   ------------------------------------------------------------
ch_read = 0
ProgDB_entries = 4
linebuf = 
path prog 1 = C:\COMMANDO\COMMANDO.PRG
prog 1 = Commando (Klapauzius)
Reading symbols from program '/home/marndt/tmp/just_delete_me/AUTO/hdmenu.prg' symbol table...
GCC/MiNT executable, GST symbol table, reloc=0, program flags: FASTLOAD TTRAMLOAD TTRAMMEM PRIVATE (0x7)
Trying to load symbol table at offset 0x13020...
NOTE: ignored 1 globally defined equated values.
NOTE: ignored 294 unnamed / local symbols (= name starts with '.L').
NOTE: ignored 17 object file names (= name has '/' or ends in '.o').
WARNING: symbols '_spw_text' & 'liblinkfile.a' have the same 0xecde address.
WARNING: symbols '_DBG_AddTrace' & 'libnatfeats_debug.a' have the same 0xee9a address.
Loaded 96 symbols from '/home/marndt/tmp/just_delete_me/AUTO/hdmenu.prg'.

CPU=$ff76, VBL=380, FrameCycles=76216, HBL=148, LineCycles=440, DSP=N/A
$0000ff76 : 4e75                               rts       
> 

i used a forced assert here...

[Eero Tamminen]

- exceptions handlers so that 2,3, or 4 bombs call the debugger

You can already tell Hatari which exceptions should invoke debugger, like this:

Code: Select all

--debug-except bus,address,autostart

Actually enabling the debugger invocation requires either the "autostart" argument, or using "-D" option. Former will enable exception debugging with Hatari program autostarting, "-D" enables it immediately. Why you normally want former, is that enabling exception catching right at start, will catch also exceptions from HW probing that TOS does at bootup.

You can toggle exception debugging from within the debugger with the same options:

Code: Select all

setopt --debug-except bus,address
setopt -D

[simonsunnyboy]

I am not using the autostart feature at the moment as I rely on TOS AUTO folder processing.
I remember having such commandl ine options i nuse but it was very very annoying to see all TOS probing for missing hardware.

Is there a chance to let my code inject the options while running? Atm I probably have to stop by hand, type something or load a script and then continue. So from a usability point of view, a dedicated handler which will use the natfeats when called sounds like a great solution to get some real usability into my code.

[Eero Tamminen]

You can still give "--debug-except" as Hatari args. Just enable the selected exceptions catching later on. You can do that from debugger manually with "setopt -D", or automate that to suitable point by using chaining breakpoints.

As to how you can chain breakpoints, see this for an example:
https://hg.tuxfamily.org/mercurialroot/ ... rg-args.sh

My (chained) debugger scripts wait until a file is opened to make sure that TOS basepage info is available, because setting breakpoint to program startup needs valid basepage.

That example expects first Fopen() to be for the TOS *.INF (autostart) file, as at that point TOS basepage pointer is surely valid. I'm not sure whether that is the case earlier in the boot process when AUTO folder programs are executed, as I've never tested that... If not, you'll see a huge amount of warnings from Hatari debugger about basepage being invalid (a warning per checked, i.e. every instruction).

Alternatively you can do all kinds of things from your program through NatFeats if you enabled NF_COMMAND in natfeats.c from Hatari sources. Or you can use --bios-intercept and XBios(255). NF_COMMAND and XBios(255) both parse the given command string like the Hatari remote interface does. I.e. you can give any debugger commands, command line options and few additional remote API commands through them. You can experiment with them using hconsole.

[Eero Tamminen]

Simon, could you check whether attached Hatari patch works also for NF_DEBUGGER natfeats command?

I'd like to replace the previous patch with this one, but I don't have a test-case with which to test it.

Btw. I have also XBios Dbmsg() implementation which would be another method to output messages and invoke debugger (if one enables XBios interception):
http://toshyp.atari.org/en/004012.html#Dbmsg

Do you think something like that would be useful (and whether any app actually used the Dbmsg() Atari debugger API )?

[simonsunnyboy]

Anything that is not a specific Hatari feature but something any emulator or real Atari could implement is a good idea. So if there already is a certain XBIOS call defined, I'd prefer to support it.

On th execeptions, I still see too much hand work to intercept it. I'll go for my own ISR and see. Atm I can work quite good without.

On the patch, I could try.

*EDIT* The patch seems to be working.