GDB 4.16 with m68k-stub target/bad stepping.
Tue Aug 12 17:15:00 GMT 1997
Brian Witt wrote:
> I'm using GDB 4.16 as cross-debugger to a M68010 machine (AT&T 3B1
> hardware without an OS). I'm having problems continuing after a
> breakpoint. Source level stepping after a breakpoint doesn't work,
> but NEXTI does.
> --> GDB 4.16 (sparc-sun-solaris2.5 --target m68k-unknown-aout),
> I started the GDB 4.13 m68k-stub.c which a previous guy had used. I
> did diffs against 4.16's m68k-stub.c, and then used `patch' to forward
> merge the changes. I'm curious if these two are compatible. Should I
> try the whole forward merge again. Is the m68k-stub a victim of bit
> Should I just hack it to work? It runs with "mc68020" defined. I've
> already modified mem2hex() to access in 16-bit words if address and
> count are even. Is "qOffsets" important. It seems to find variables
> OK without it. The code loads into a specific location. There is no
> dynamically placed code.
> (Gosh, this message got long...)
> Anyone got any ideas to help me out?
> The problem in my code is the push before the call to sbrk() is getting
> skipped. Garbage is used and sbrk() sez "too much" and returns -1.
> The second word of "pea 0x2000" turns into "movel d0,d0".
> It seems the PC sent to the host is *after* the breakpoint (normal
> processing for the TRAP #15 instruction). The breakpoint occurs as it
> should. GDB resumes execution starting at the next short (2-bytes)
> after the breakpoint (after the inserted TRAP instruction). In most
> cases is needs to be backed up once the original instruction is
> restored by GDB.
> For instance (with "set remotedebug 1 ; set remote_debug = 1")
> Address 0x35c2 is an instruction boundary ("pea 0x2000") which is
> "whole_block = sbrk(0x2000);". Address 0x7efec is on the stack.
[snip trace stuff]
> orib #-1,%a4
I also found this problem in the stub. I am using a 68000. My solution was to adjust
the PC back 2 bytes in '_catchException' to the original break point. Seems to work
Here is a patch against the original in gdb-4.16. I took this mod from my hacked
version and put it back into the original. I have not tested it. I have not touched
or tested the 68020 part of the stub.
FYI, the breakpoint trap for my stub is TRAP #1 not TRAP #15 !
[cjohns@wombat]$ diff /awa/gnu/src/gdb-4.16/gdb/m68k-stub.c.orig
> cmpiw #33,d2 /* trap #1, breakpoint ? */
> bne not_breakpoint
> subql #2,a4 /* trap leaves the pc after the trap */
< (frame->exceptionPC == (newPC+2))) break;
> (frame->exceptionPC == newPC)) break;
Chris Johns Networks, Plessey Asia Pacfic Pty. Ltd.
More information about the crossgcc