This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: More GDB stub questions


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]