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]

Re: GDB 4.16 with m68k-stub target/bad stepping.


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