making gdb-stub work from rom

Well after some long break I'm back on the m68k... I had time to draw some of the schematics of the circuit, only the CPU and most of the support circuitry. The rest of the circuit is straight forward, I connected my EPROM emulator and a massive 512K bytes SRAM to the bus and finally a MC68901 Multi Function Peripheral (MFP) handling the serial port and SD card interface. The CPU clock is at the moment 4MHz, so I can share it with the MFP, later I intend to clock the CPU at 8MHz.
Since my previous post, I've done/settled on a couple of things:

1. I'll use gcc and gdb to do get the system up and running. Currently I managed to compile gcc-3.4.6 for target m68k-elf and gdb-6.8;
2. I've created basic linker scripts for running from ROM and running from RAM. Both have been proven to work with C source (C++ probably won't work). I've also created two CRT0.S for each of these linker scripts;
3. Compiling the gdb-stub and link it to ROM proved a big challenge, but I managed in the end. The source m68k-stub.c that comes with gdb suffers from severe bit rot, most of the assembly source doesn't compile either because the syntax is no longer supported or because "handling multi line strings has changed in 2001";
4. Still doesn't work perfect, the first time I load, break main and continue, remote-gdb ends up "somewhere", on the second time I load and continue (no need to break main, this is handled by the server) it works OK and I can even step lines of code. This probably has to do with my "trick" to make gdb-stub work from ROM without referencing any program at all (the frame information is not correct... I think...). On the second run (after the initial crash), this frame is correctly initialized.
5. I'll add a 3V power supply and a SD Card interface for "disk drive", based on some previous work I did with the Arduino, I don't expect big difficulty.
6. Placing the vectors in memory was actually quite easy, I needed to learn some m68k assembly and now I do it in CRT0.S. Due to a requirement of the gdb-stub to identify the generated exception, I had to build a two step exception processing. First the vectors 0 to 256 are initialized to unique locations starting at 0x400 in steps of 8. On each of these, 8 bytes there's a NOP and a Jump to Sub Routine long to the exception_handler, this pushes a unique address per exception on to the stack, the exception_handler pops this address and identifies the exception that was generated.

I had a old monitor that I "pop" from storage, to test dual head with openSUSE 11.2 and it works great. I really think it's a great advantage to work with two monitors, one for programming other for debugging or one for drawing the circuit and the other to check the PCB, Bill of Materials, Stocks, vendors, spreadsheet, etc.
Another thing I noticed is that I still can't get away from printouts of the code.. and I wish I had an old matrix printer with form paper... those were the days...