This is the mail archive of the
mailing list for the GDB project.
Re: gdb 7.2 with m68k-stub as remote target
- From: Petr HluzÃn <petr dot hluzin at gmail dot com>
- To: JoÃo Silva <jcferreiradasilva at yahoo dot com>
- Cc: gdb at sourceware dot org
- Date: Sun, 9 Jan 2011 18:19:06 +0100
- Subject: Re: gdb 7.2 with m68k-stub as remote target
- References: <email@example.com>
On 3 January 2011 23:08, JoÃo Silva <firstname.lastname@example.org> wrote:
> 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.
(This seems to be m68k-specific. I am not familiar with the arch.)
> 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.
Yes, you implemented it correctly.
A stub is responsible for all breakpoint handling. This is because
different targets/archs use different ways how to implement
breakpoints. Some targets use break instructions (possibly with
different lengths), some use debugging registers in CPU, some use jump
instruction - this affects how to continuation is handled. I think it
is easier to have to implement more code (rollback PC, restore
original instruction, single-step, place breakpoint instruction again,
continue) than to try to understand how to do a more
sophisticated/complicated interaction with GDB.
The remote protocol documentation  probably should mention what is
expected by a stub.
GDB Internals mentions some of that