[Coco] xroar host debugger project?

[Joel Rees]

On Sun, Sep 18, 2022 at 3:16 PM Ciaran Anscomb via Coco
<coco at maltedmedia.com> wrote:
>
> Joel Rees via Coco wrote:
> > > [...]
> > > Is the "disassemble" command enough?
> > [...]
> >
> >
> > 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.)
>
> Can I just be sure you're not talking about attaching GDB to an XRoar
> process here?  I'm talking about the port XRoar can listen on (with the
> -gdb option) that GDB can connect to.

Without the patches, I don't think I have anything to attach to but
the SRoar process.

> You've mentioned remote targets so I don't _think_ this is a point of
> confusion, but just in case...  ;)
>
> So you don't need to know where the XRoar process keeps its RAM, you
> just attach GDB to it (preferably patched to know about 6809) and just
> ask for the emulated information.

I did try a remote connection with an unpatched server, but I couldn't
figure out where to go from there.

> The theory was that a more fancy GUI could talk the same protocol and
> control the emulated machine through the GDB TCP connection, but I think
> the guy that wanted to work on it back then got hit by a bad case of life.

That's happened to me a couple of times, too. Or maybe I was the guy.
I was trying to debug a port of fig Forth to the 6809 and running into
basically the same kind of issues a couple of years back or so.

> (And if you yourself want to attempt similar, GDB supports custom
> protocol additions - the 'q' commands - so we should be able to allow
> inspecting/changing other bits of hardware than the RAM, too).

I've been thinking that direction, as well.

> > Building the patched version of gdb -- will that require messing
> > around in /dev or such? Or can the patched debugger run in userland?
>
> No, userland: http://www.6809.org.uk/dragon/m6809-gdb.shtml

That page shows the command

   git clone -b m6809-7.6 https://www.6809.org.uk/git/binutils-gdb.git

So I tried the clone, exactly as written, and the clone just never
starts. I have to ctl-C to get my terminal back after waiting two or
three minutes, and there's nothing in the directory I'm cloning to.

You have this note:

    2016-05-30: This repository has changed because the source
repository for GDB changed. It is now based on
git://sourceware.org/git/binutils-gdb.git ,

But I nosed around in there and didn't see patches for the 6809, and
trying to clone that, the branch m6809-7.6 is not found.

> I did write a quick & dirty getting started note here:
>
> http://www.6809.org.uk/tmp/xroar/m6809-gdb.txt

That does look good, if I can get the repository.

Thanks for walking me through this.

-- 
Joel Rees

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