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

[Triple Yang <triple.yang@gmail.com>]

2011/8/15 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
>

Besides his Howto: Porting the GNU Debugger and Howto: GDB Remote
Serial Protocol, yes,
Those materials have done a very good help to me.

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

Oh, God, I just didnot catch the essential. I was so careless. Forgive me.

>> 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.
>

You are right, and I misunderstood.

Thanks a lot for your detailed and informative explanation.

Best regards.

> --
> Pedro Alves
>