What role does gdb/remote.c play?

What role does gdb/remote.c play?

[yongyong.yang]

Hey, everyone.
 
Recently I am trying to port gdb for a remote target. I use remote-m32r-sdi as start point.
when I debug it, I find the global variable current_target has the value specified in remote.c, 
furthermore I find the generated file init.c has both initialize_XXX() and _initialize_remote() , 
where XXX is the target I specified for my target.
 
So when I run command 'target remote localhost:[port]', it is remote_open() that handles the argument and etc.
 
Can someone explain what is wrong. Thank you.

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

[Pedro Alves]

On Monday 15 August 2011 10:08:28, yongyong.yang@ia.ac.cn wrote:
> Hey, everyone.
>  
> Recently I am trying to port gdb for a remote target. I use remote-m32r-sdi as start point.
> when I debug it, I find the global variable current_target has the value specified in remote.c, 
> furthermore I find the generated file init.c has both initialize_XXX() and _initialize_remote() , 
> where XXX is the target I specified for my target.
>  
> So when I run command 'target remote localhost:[port]', it is remote_open() that handles the argument and etc.
>  
> Can someone explain what is wrong. Thank you.

GDB supports more than one method to talk to the remote target.
To connect to a remote target using remote-m32r-sdi.c, you issue
"target m32rsdi".  See:

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

"target remote" maps to remote.c, which uses the
GDB Remove Serial Protocol (RSP, see the GDB manual) to control
target.  New targets are strongly encouraged to
implement RSP support on the remote end, instead of cooking up a
new gdb remote backend.

-- 
Pedro Alves

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

[Triple Yang]

Thank you very much.

Then, if I want to create a new remote target, should I just modify
remote.c or reuse codes in it? How do I map command 'target remote' to
the new target I created?

It seems I did what those documents told me to, but things don't work.

Best wishes.

在 2011年8月15日 下午6:09，Pedro Alves <pedro@codesourcery.com> 写道：
> On Monday 15 August 2011 10:08:28, yongyong.yang@ia.ac.cn wrote:
>> Hey, everyone.
>>
>> Recently I am trying to port gdb for a remote target. I use remote-m32r-sdi as start point.
>> when I debug it, I find the global variable current_target has the value specified in remote.c,
>> furthermore I find the generated file init.c has both initialize_XXX() and _initialize_remote() ,
>> where XXX is the target I specified for my target.
>>
>> So when I run command 'target remote localhost:[port]', it is remote_open() that handles the argument and etc.
>>
>> Can someone explain what is wrong. Thank you.
>
> GDB supports more than one method to talk to the remote target.
> To connect to a remote target using remote-m32r-sdi.c, you issue
> "target m32rsdi".  See:
>
> $ 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";
>
> "target remote" maps to remote.c, which uses the
> GDB Remove Serial Protocol (RSP, see the GDB manual) to control
> target.  New targets are strongly encouraged to
> implement RSP support on the remote end, instead of cooking up a
> new gdb remote backend.
>
> --
> Pedro Alves
>

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

[Pedro Alves]

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.

> 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

-- 
Pedro Alves

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

[Triple Yang]

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
>

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

[Andrew Burgess]

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.

> 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

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

[Pedro Alves]

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

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

[Petr Hluzín]

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

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

[Triple Yang]

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

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

[Triple Yang]

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
>

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

[Triple Yang]

2011/8/15 Petr Hluzín <petr.hluzin@gmail.com>:
> 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.
>

So in option B or C, will reusing codes in remote.c be satisfying?
(Thus I may save some time in writing codes parsing/wrapping RSP
packets.)

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

Best regards.

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

[Petr Hluzín]

On 15 August 2011 20:20, Triple Yang <triple.yang@gmail.com> wrote:
> 2011/8/15 Petr Hluzín <petr.hluzin@gmail.com>:
>> On 15 August 2011 17:09, Triple Yang <triple.yang@gmail.com> wrote:
>>> 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.
>>
>
> So in option B or C, will reusing codes in remote.c be satisfying?
> (Thus I may save some time in writing codes parsing/wrapping RSP
> packets.)

No, you cannot reuse code in [1]. GDB uses the code to format commands
and parse responses.

You can reuse code of gdbserver in [2]. This directory includes the
code for parsing commands from GDB and formatting responses.

However there are many more implementations of a GDB remote
monitor/stub in the world, the gdbserver is just one of them.

[1] http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/remote.c?cvsroot=src
[2] http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/gdbserver/?cvsroot=src

-- 
Petr Hluzin