gdb 7.2 with m68k-stub as remote target

[João Silva <jcferreiradasilva at yahoo dot com>]

Hello all,
sorry to bother you all with an old target m68k, but I need some help or maybe I can help and do the changes myself but I need to know where.
I've built a m68008 minimum system and I connected through a serial line (RS232), built the cross-tools (gas,ld,gcc) and libraries. Finally, from the GDB sources, I've built the m68k-stub.
So that you (maintainers) know the m68k-stub suffers from some bit rot, the assembly format is no longer supported and multi line assembly has also changed (but it is doable).
My gdb was configured with:
./configure --host=i686-pc-linux-gnu --target=m68k-elf --prefix=/opt/m68k
Currently I have few problems/issues:
1. The trap inserted by gdb is not TRAP 1 as it is implicitly defined in the stub (by catching the relevant exception and reporting Signal 5 - Breakpoint) but TRAP #F. I found a piece of code (m68k-tdep.c:60) that could explain it but I found not way to define BPT_VECTOR, it should be possible to change it during configure (how?). Also there's a reference to in gdb internals to BPT_VECTOR and REMOTE_BPT_VECTOR (defaulting to 1, which would be correct) but the latter has been removed from any source file.
2. I have two types of breakpoints (TRAP #0) for program breakpoints (in the source) and GDB inserted breakpoint (TRAP #F). When my program encounters a program breakpoint, control is returned and when execution is continued, control is passed to the instruction following the TRAP. When I continue after a GDB inserted breakpoint, control was passed to the instruction following the trap, which is an error (PC should be rolled back). I solved it in the stub, by rolling back if it was a GDB inserted breakpoint, but shouldn't it be possible to do this in GDB? (I can do it manually with $pc-=2 and no intervention from the stub).
3. My final problem is "continue" after a GDB inserted breakpoint. When the program hits the inserted breakpoint, changes the TRAP #F opcode for what was there (correct), but I continue, before giving control back to my program the instruction is changed back to TRAP #F, since I rolled back the PC, I hit the same breakpoint without the program to continue. I think that what should happen is first a single step (to skip the breakpoint place), re-insert breakpoint and continue.(from gdb internals page 67, gdbarch_skip_permanent_breakpoint). I'm currently solving this by manually doing it.
Sorry for the long description, if nobody works on these old targets please just give me a note and I'll silently get out of you way.
Thanks,
JCSilva