What is the goal of all this?
I have never understood what he wants to do. In first place,
there is no need for another softcore, we already have NIOS, LEON, ZPU, etc, also we have hybrid solution like ARM+FPGA (e.g. DE1 board), able to run linux (OpenRISC has now a specific uclibc stage 4), while his softcore comes with no TLB (no MMU), no cache, and a very reduced exception engine: in short, even if there are board with arduino-line pins, it's less useful than an arduino!
for hobby (good occasion to learn by having fun) I have already designed and suggested him a debug TAP, I have designed its protocol to be the easiest, I have written the host interface in C (with wrappers to simplify both the module test and the system integration test), but he refuses everything because he want the goddam gdd, which costs a very complex engine, especially if you also want the jtag
I am a bit tired about his project, I am tired to provide him solutions which he refuses for his motivation, which sounds "I MUST use gdb, I MUST have jtag" (even if it's for hobby purpose, I do not believe it's for commercial, as there is no need for an other soft core, and in case { ZPU, LEON, NIOS*, *BLAZE } have a better support by sever order of magnitude)
I have already written a linker-script, a full-patch for gcc-mips in order to force alignment load/store (in order to simplify the exception handler, as his softcore is not able to handle unaligned memory access exceptions, and it comes with no dedicated instructions, still to be implemented and tested), a bsp, everything integrated within geany with automagically generation of makefile,
but he is still using the manual way with no linker script, which makes everything more complex to be handled as it requires more manual work
it is not like the rest of GDB is beautiful
things made by G-boys (G stands for GNU) are always thousand light years far from the concept of being simple and beautiful, these guys are complex by design, and sometimes (too often) they cause more problems than how many they solve, e.g. tar worked on UNIX until they have "improved" and since then we still have a lot of troubles
gdb is a very complex amount of stuff, even if the gdb-stub is simple, the gdb engine goes complex
For hobby use, I don't think the debugger is necessary at all, but I'm generally biased against debuggers.
it's useful and funny when you have to verify what happens inside a softcore and you can trust the software because you can't trust the hardware because bugs are there
e.g. his softcore had a lot of bugs with "delayed branch" plus other bad things, so the "monitor" (a piece of software, written in assembly, and able to catch exceptions, interrupts, and able to dump the CPU-registers content) was bugged because of these hardware bugs, so register RA was reported completely wrong (which made me things a bug in the C compiler) when the problem was elsewhere
when I implemented my TAP, I was able to show him where was the bug, even if is he refuses to use my TAP because he wants his damn GDBGDBGDBGDBGGDB even if it never comes into a working & stable state
let me say: sometimes being stubborn in things which have already proved to be the wrong choice (perhaps because they are too complex, perhaps you can't implement it in a comfortable way), makes you to look like the best moron ever!