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

[Pedro Alves <pedro@codesourcery.com>]

On Monday 15 August 2011 16:09:44, Triple Yang wrote:
> 2011/8/15 Pedro Alves <pedro@codesourcery.com>:
> > On Monday 15 August 2011 12:51:11, Triple Yang wrote:
> >
> >> Then, if I want to create a new remote target, should I just modify
> >> remote.c or reuse codes in it?
> >
> > I don't know what your new target does, so I can't answer that for you.
> >
> >> How do I map command 'target remote' to the new target I created?
> >
> > You don't.  Do you _really_ need to implement a new target in gdb?
> > Why not teach the remote end the RSP instead?  Then you can
> > use "target remote", without adding new code to gdb.
> >
> 
> Yes, because I am trying porting GDB to a new architecture prototype.
> Implementing a new target seems to be the only way to achieve the
> purpose.

New architecture support does not require a new target_ops instance.
For example, you can connect gdb to all of arm-linux, powerpc-linux,
mips-linux, x86-linux, x86-windows, etc. gdbservers all through the
same "target remote" (remote.c) command, all from the same build of gdb
hosted on e.g., x86-linux.  Architecture support should be host
independent, and implemented on the *-tdep.c files.  E.g., start looking
at arm-tdep.c, at arm_gdbarch_init.  "gdbarch" is the structure
that knows everything about an architecture.

> To "teach the remote end the RSP instead", what needs to be done?

You need to teach what you're connecting to, to support the RSP
protocol.  Teach it the memory read/write packets, the register
read/write packets, the step/continue packets, stop replies, etc..
Try connecting to a gdbserver running on your computer, with

$ gdbserver :9999 /foo/program/to/debug

on another shell:

$ gdb /foo/program/to/debug
...
(gdb) set debug remote 1
(gdb) tar remote :9999

and you'll see the RSP traffic.

I think Jeremy Bennett's howto is likely to be of help:
http://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html

> The Question is, when I created my own "struct target_ops" object and
> initialized it properly, then added it to targetlist, I could expect
> it would respond to commands like target remote and break.

Your expectation is wrong, sorry.  It will react to "target FOO", with
FOO being the target's short name, as in the list in one of my previous
emails:

$ 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";

> As I've mentioned in a previous mail, current_target holds the value
> specified in remote.c rather than my own remote-XXX.c. I guess the
> expected value is overrided in init.c (which is a generated file
> during building) since _initialize_remote() is called after calling
> _initialize_remote_XXX(). It is easy to find an ugly and offensive way
> to avoid that situation. But I tend to believe there are some clean
> and pretty means to do that and I don't know yet.

There's no means for that, because that's the wrong thing to do, sorry.

-- 
Pedro Alves