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

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

2011/8/15 Andrew Burgess <aburgess@broadcom.com>:
> On 15/08/2011 16:09, Triple Yang wrote:
>
>> 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.
>
> The commands "target remote" and "break" are different, the "target remote"
> is used to pick which "struct target_ops" is used to talk to a target,
> commands like "break" use the functions linked into the "struct target_ops"
> in order to do debugging stuff with your target.
>
> The remote in "target remote" comes from the to_shortname field of the
> struct target_ops. If you have created your own struct target_ops then you
> should fill this field in with a unique target name, say xxx, you can then
> say "target xxx" and gdb will use your struct target_ops to talk to the
> target.
>

Great! I think that's exactly the point where I made mistakes. I'm so
grateful for your concise and meaningful explanation.

Best regards.

>> 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.
>
> The calls to _initialize_<whatever> build up the total list of all possible
> targets. Just having a target in the list doesn't mean it's being used, a
> target type is selected when you issue the target <type> command to gdb.
>
> Andrew
>
>