This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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 > rot? > > 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? > > Description > ----------- > > 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 > 68-gdb> > ------------------------- 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 fine. 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 /awa/gnu/src/gdb-4.16/gdb/m68k-stub.c 431a432,438 > > cmpiw #33,d2 /* trap #1, breakpoint ? */ > bne not_breakpoint > > subql #2,a4 /* trap leaves the pc after the trap */ > > not_breakpoint: 883c890 < (frame->exceptionPC == (newPC+2))) break; --- > (frame->exceptionPC == newPC)) break; -- Chris Johns Networks, Plessey Asia Pacfic Pty. Ltd. mailto:ccj@acm.org mailto:cjohns@plessey.com.au