This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: What role does gdb/remote.c play?
On 15 August 2011 17:09, Triple Yang <triple.yang@gmail.com> 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.
If your users want to debug programs running on a remote
machine/device then you can either:
A: override "target remote" (or other target) implementation in GDB
and use custom communication or
B: use GDB's remote protocol, modify gdbserver sources and write your
own handling or
C: use GDB's remote protocol and write your own parsing and handling
The option A is not recommended (see Pedro Alves) because it either
means you will be distributing your own GDB or be stuck to FSF release
schedule. Also users of older gdbs will not be able to connect (plus
users will get misleading diagnostic). And there is a lot of code in
gdb and many ways to get lost.
For options B and C the user would type "target remote" and it will
behave the way users expect from other archs (as the case may be),
what tutorials describe and what IDEs do well.
> To "teach the remote end the RSP instead", what needs to be done?
On remote system do create a listening TCP socket and implement
processing the remote protocol commands [1]. The gdbserver does that
for several architectures and can serve as an inspiration.
[1] http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Protocol.html
--
Petr Hluzin