[Coco] xroar host debugger project?

[Joel Rees]

Ciaran Anscomb via Coco wrote:
>
> Joel Rees via Coco wrote:
> > This is primarily for Ciaran, but I'm wondering if anyone else has
> > thought about adding a built-in debugging interface to xroar, either a
> > front-panel style interface or a host command-line style interface.
>
> Only in a "it would probably be nice..." way myself.  The reason for
> me adding the GDB interface in the first place was that someone else
> had expressed interest in developing an external tool to visualise
> such things, and GDB stub as a protocol seemed like the obvious way to
> expose things.  Patching GDB itself wasn't too much effort at the time
> (though everything's changed since then).

The reason I'm asking is that I once had the skilz to do this kind of
thing, and I have several projects for the 6809 that are stuck at the
point of needing a way to see what's going on inside memory. All the
debuggable emulators I can find (ADTASM+ included) are cluttered by
stuff that keeps me from getting a look at what I need to get a look
at. So I'm looking at adding 6809 emulation to Joe Allen's EXORsim or
adding a debugging interface to XRoar or writing my own
emulator/debugger myself.

> > I'm trying to get a dumb transliteration of VTL-2 (6801) running on
> > the Color Computer, and I'm needing to look at the list of program
> > lines in memory after a line insertion, and poking stuff to the screen
> > has limits. And I'm not seeing how to do this on gdb remote, which is
> > probably my lack of experience with gdb.
>
> Is the "disassemble" command enough?

I'm needing to look at the lines of VTL program source in memory.
Something that works on the 6801 to keep the loops bounded is not
working on the 6809 in the Coco emulation. If I got intimate enough
with XRoar to know where your RAM emulation array is, I could probably
use un-patched gdb to show me the array contents. But looking for that
last night, I didn't see what I expected.

And if I get that familiar, I'm thinking maybe I could dig a little
deeper and add the debugger UI. It looks like most of the internal
pieces are in place. (Famous last words, sure.)

> https://visualgdb.com/gdbreference/commands/disassemble
>
> # Start XRoar with GDB stub enabled (default localhost:65520)
>
> $ xroar -gdb &
> [...]
>
> # Connect m6809-gdb to XRoar
>
> $ m6809-gdb
> [...]
> (gdb) target remote localhost:65520
> Remote debugging using localhost:65520
> 0x0000bbca in ?? ()
> (gdb) disassemble /r 0x8000,+16
> Dump of assembler code from 0x8000 to 0x8010:
>    0x00008000:  7e bb 3c        jmp     $bb3c
>    0x00008003:  7e bb 88        jmp     $bb88
>    0x00008006:  7e bb e5        jmp     $bbe5
>    0x00008009:  7e bb b5        jmp     $bbb5
>    0x0000800c:  7e bc ab        jmp     $bcab
>    0x0000800f:  7e bd 1a        jmp     $bd1a
>
> You can also type "layout asm" and it'll divide the screen showing a
> disassembly from the current PC above the interactive area.
>
> Most of the basic assembly-level functionality of GDB seems to work,
> eg watch for writes to the first byte of text screen memory:
>
> (gdb) watch *((char *)0x0400)
> Hardware watchpoint 1: *((char *)0x0400)
> (gdb) c
> Continuing.
>
> (then say clear the screen...)
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x0000ba80 in ?? ()

Building the patched version of gdb -- will that require messing
around in /dev or such? Or can the patched debugger run in userland?

-- 
Joel Rees

http://reiisi.blogspot.jp/p/novels-i-am-writing.html