Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "William A. Gatliff" <bgat@billgatliff.com>
To: Squal <pmarty@enssat.fr>
Cc: gdb@sources.redhat.com
Subject: Re: remote debugging with m68k-stub
Date: Wed, 07 Aug 2002 08:17:00 -0000	[thread overview]
Message-ID: <20020807101751.B5941@saturn.billgatliff.com> (raw)
In-Reply-To: <3D511895.F61D82A1@enssat.fr>; from pmarty@enssat.fr on Wed, Aug 07, 2002 at 02:54:45PM +0200

Pascal:


Here's a short list of things I usually screw up:

* Is someone setting up the bus state controller and other critical
peripherals properly before you download your program?

* Does the stub put the stack pointer in a useful place for the
application?  Does the application need to move its stack pointer to a
larger memory space durining initialization?

* Is application code accidentally getting placed on the stub or
application stack space?

* Are you downloading the program properly?  If you disassemble memory
after typing 'load' at the gdb prompt, you should see your code.

Immediate halts, in my case, usually signal a problem in the handoff
between the stub and the application during the 'step' and 'continue'
commands.  Focus on those parts of your implementation.

You don't need an "application" to test your stub.  Just use a memory
write command to write the opcode for TRAP #1 (or whatever your stub
will use for the breakpoint opcode) to a known memory location, read
it back to verify that it's there, set the PC to that address, and do
a continue.  You should get an immediate breakpoint exception.

Throw in a few NOP opcodes, and you can test 'stepi' as well.  Once
'continue' and 'stepi' are working, you're usually in pretty good
shape.

If you'd like a second stub implementation to use as a guide, see the
gdbstubs project at http://sourceforge.net/projects/gdbstubs .  It
supports CPU32.


HTH,


b.g.

On Wed, Aug 07, 2002 at 02:54:45PM +0200, Squal wrote:
> Hello!
> 
> I have done all the remote target gdb instructions:
>   - define all the low level routines
>   - insert set_debug_traps(); and breakpoints(); at
>     the beginning of the program
>   - compiling stub and program together
> 
> After that, I downloaded my program and the m68k-stub in the target. 
> My problem is when I start the program in the remote target, the program
> stop and never restart (the halt indicator is set).
> Normally, the program will stop at the breakpoint (TRAP #1) and will
> continue after gdb be connected to the stub but the program seems to 
> be stopped.
> 
> Somebody can help me ?
> 
> Thanks
> 
> Pascal

-- 
Bill Gatliff
bgat@billgatliff.com


  parent reply	other threads:[~2002-08-07 15:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-07  5:49 Squal
2002-08-07  7:22 ` Quality Quorum
2002-08-07  8:17 ` William A. Gatliff [this message]
2002-08-14  2:34 Squal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020807101751.B5941@saturn.billgatliff.com \
    --to=bgat@billgatliff.com \
    --cc=gdb@sources.redhat.com \
    --cc=pmarty@enssat.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox