Re: What role does gdb/remote.c play?

[Pedro Alves <pedro@codesourcery.com>]

On Monday 15 August 2011 10:08:28, yongyong.yang@ia.ac.cn wrote:
> Hey, everyone.
>  
> Recently I am trying to port gdb for a remote target. I use remote-m32r-sdi as start point.
> when I debug it, I find the global variable current_target has the value specified in remote.c, 
> furthermore I find the generated file init.c has both initialize_XXX() and _initialize_remote() , 
> where XXX is the target I specified for my target.
>  
> So when I run command 'target remote localhost:[port]', it is remote_open() that handles the argument and etc.
>  
> Can someone explain what is wrong. Thank you.

GDB supports more than one method to talk to the remote target.
To connect to a remote target using remote-m32r-sdi.c, you issue
"target m32rsdi".  See:

$ grep "to_shortname = " src/gdb/remote*.c
remote.c:  remote_ops.to_shortname = "remote";
remote.c:  extended_remote_ops.to_shortname = "extended-remote";
remote-m32r-sdi.c:  m32r_ops.to_shortname = "m32rsdi";
remote-mips.c:  mips_ops.to_shortname = "mips";
remote-mips.c:  pmon_ops.to_shortname = "pmon";
remote-mips.c:  ddb_ops.to_shortname = "ddb";
remote-mips.c:  rockhopper_ops.to_shortname = "rockhopper";
remote-mips.c:  lsi_ops.to_shortname = "lsi";
remote-sim.c:  gdbsim_ops.to_shortname = "sim";

"target remote" maps to remote.c, which uses the
GDB Remove Serial Protocol (RSP, see the GDB manual) to control
target.  New targets are strongly encouraged to
implement RSP support on the remote end, instead of cooking up a
new gdb remote backend.

-- 
Pedro Alves