This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: What role does gdb/remote.c play?
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.
To "teach the remote end the RSP instead", what needs to be done?
>> It seems I did what those documents told me to, but things don't work.
>
> I'm confused. ÂWhat documents? ÂI only pointed you at the GDB manual,
> to check the RSP documentation. ÂHere:
>
> http://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html
>
I have already read about those related codes and official documents.
I barely grasp the main points. Maybe I should dive into gdb source
codes. But I am not sure.
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.
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.
Best wishes.
> --
> Pedro Alves
>