This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb 7.2 with m68k-stub as remote target


Hello

On 3 January 2011 23:08, JoÃo Silva <jcferreiradasilva@yahoo.com> 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 [1] probably should mention what is
expected by a stub.
GDB Internals mentions some of that [2]

[1] http://sourceware.org/gdb/current/onlinedocs/gdb/Packets.html#index-g_t_0040samp_007bz_007d-packet-2445
[2] http://sourceware.org/gdb/current/onlinedocs/gdbint.html#Algorithms

-- 
Petr Hluzin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]