[Libre-soc-bugs] [Bug 499] Create experimental gdb protocol implementation in nmigen for debugging

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=499

--- Comment #8 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #6)

> I'm not saying we should completely replace JTAG, I'm saying we could and
> also that GDB's protocol is nicer for debugging and requires less pins.

openocd already integrates directly with gdb, and it's only 2 pins.  if
it was 20 or 200 i'd be concerned.

if you run the simulation (litex/florent/sim.py) then type "openocd -f
openocd.cfg" it will fire up an openocd instance that acts as a "gateway"
between the jtagremote TCP port, and it is a trivial matter to put into
the openocd.cfg fike "please fire up a remote gdb service".

you then fire up gdb with options that connect to that port.

this does *exactly the same job" as connecting gdb to a serial port.

> > > One of the nice features of GDB's protocol is it supports debugging
> > > multi-threaded programs (we would interpret gdb's threads as processor
> > > cores). I don't know if the jtag protocol supports that.
> > 
> > both serial and JTAG are single resource and immediate response.  any multi
> > threading is done at the software level (as part of gdb)
> 
> My point was that gdb's protocol already has built-in handling for things
> like "send a signal (interrupt) to thread #7" or "read registers from thread
> #5" or "pause thread #1" or "resume thread #2". 

whatever is available in the gdb protocol is *already* going to be proxied
over the jtagremote protocol as well.

> This will be useful for
> later chips that have multiple cores, since we'd just tell gdb that a chip
> with 4 cores has 4 gdb-visible threads.

then all we need do to support that is to add the "hyperthread" number to
the JTAG HDL, most likely one of the DMI registers.

then we add software support in openocd which being software if we screw it
up it's easy to fix.

if you really want to feel free to go ahead with this: i'd recommend that
you outline and document a full project plan.

however please bear in mind that by deciding to spend your time on this
it will be to the detriment of the project because there are much more
important things that you could be doing, such as writing an openocd
jtagremote client/server that will allow us to use Staf's SVF files,
and many other tasks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.