Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Mitchell Fang <mitchell.fang@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: More GDB stub questions
Date: Sat, 11 Feb 2006 02:29:00 -0000	[thread overview]
Message-ID: <20060211022913.GA8659@nevyn.them.org> (raw)
In-Reply-To: <cbd6ac8b0602101748p59452d51wcccd2ca3aad48f2@mail.gmail.com>

On Fri, Feb 10, 2006 at 05:48:10PM -0800, Mitchell Fang wrote:
> So I've implementing a GDB stub thats connect GDB to a PowerPC4xx
> board (target) via a JTAG controller. I've got some questions that I'm
> still not sure about and since I got great advice last time I figured
> I try again.  So here is my environment, the host computer is a linux
> machine and my GDB stub resides on the host also.  They connect by
> TCP/IP.
> 
> 1) Do I need to configure GDB so that the host is linux and the target
> is PPC?  I don't think so but wanted to be sure.

Yes, certainly.

> 2) When GDB connects with the stub, one of the initial commands will
> be the 'g' read general register commands.  Is this only the GPR
> registers then?  Shouldn't it need to know the SPR registers, and
> other registers also?  I'm not really sure what GDB is expecting. 
> When I type "info registers" afterward it just lists some stuff that I
> don't know what it is.

Type "maint print registers" to see what registers GDB is expecting and
where in the 'g' packet they ought to be.  Currently GDB has somewhat
limited support for SPRs, but if you set the architecture
appropriately, it does know some of them.

> (top-gdb) target remote :8888
> Remote debugging using :8888
> 0x00000000 in ?? ()
> (top-gdb) info register
> eax            0x0      0

That should tip you off that you don't have a PPC debugger :-)

> 3)  For the program that I want to debug, I've been trying load it
> onto the Target by using the GDB load command.  So when I type in gdb
> "load test", my stub just reads it as a write hex data to memory.  I
> haven't implemented the 'X' write bin data to memory command.  If
> that's all load does, how are you suppose to figure out where to set
> the PC?  or is this just not the right way to load the program to be
> debugged onto the Target.

Setting the PC is supposed to be done by some other mechanism.  For an
experimental stub I've been working with lately, we decided to use
"target extended-remote" instead of "target remote", which allows us to
use the "run" command ("R" packet) to set the PC appropriately.  If the
PC is the only thing that needs setting up, you can just use "load"
and start the program by an appropriate "jump" command.

-- 
Daniel Jacobowitz
CodeSourcery


      reply	other threads:[~2006-02-11  2:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-11  1:48 Mitchell Fang
2006-02-11  2:29 ` Daniel Jacobowitz [this message]

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=20060211022913.GA8659@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb@sourceware.org \
    --cc=mitchell.fang@gmail.com \
    /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