The right way to port GDB to a new architecture

The right way to port GDB to a new architecture

[Andreas Olofsson]

I have been reading through the GDB documentation and I need some
advice on the best approach to porting GDB to a new architecture
before I dive into the porting process..

Describing the architecture doesn't seem too bad and is well described
in Jeremy Bennett's document "Howto: Porting the GNU debugger".  How
to actually communicate with the target looks to be more of a
challenge and there seem to be a number of different approaches.

Possible approaches(we already have bfd, binutils, gcc, and all the
other stuff ported):

1.) Use cgen or sid to generate a gdb compliant simulator and link in
the simulator library.  Since we will need the remote debugging option
eventually, I am thinking that integrating a cgen based simulator with
GDB would be extra work and I would like to skip this step if
possible.

2.) Write a stub for the target and use remote serial protocol.  The
included stubs in the distribution are quite old?  Is this no longer a
preferred method?

3.) Port gdbserver to the new architecture. Is it a requirement to
have linux running on the target?  Based on the ports I have seen in
GDB it would seem to be the case? Why doesn't the ARM have a stub for
example?  I can't imagine you have to run linux on an arm based device
to be able use remote GDB?

4.) Another approach?

If we assume that the target is not running linux, what would be a
good starting point to work from: m32r?

Andreas

Re: The right way to port GDB to a new architecture

[Jeremy Bennett]

On Tue, 2009-01-13 at 10:39 -0500, Andreas Olofsson wrote:
> I have been reading through the GDB documentation and I need some
> advice on the best approach to porting GDB to a new architecture
> before I dive into the porting process..
> 
> Describing the architecture doesn't seem too bad and is well described
> in Jeremy Bennett's document "Howto: Porting the GNU debugger".  How
> to actually communicate with the target looks to be more of a
> challenge and there seem to be a number of different approaches.
> 
> Possible approaches(we already have bfd, binutils, gcc, and all the
> other stuff ported):
> 
> 1.) Use cgen or sid to generate a gdb compliant simulator and link in
> the simulator library.  Since we will need the remote debugging option
> eventually, I am thinking that integrating a cgen based simulator with
> GDB would be extra work and I would like to skip this step if
> possible.
> 
> 2.) Write a stub for the target and use remote serial protocol.  The
> included stubs in the distribution are quite old?  Is this no longer a
> preferred method?
> 
> 3.) Port gdbserver to the new architecture. Is it a requirement to
> have linux running on the target?  Based on the ports I have seen in
> GDB it would seem to be the case? Why doesn't the ARM have a stub for
> example?  I can't imagine you have to run linux on an arm based device
> to be able use remote GDB?
> 
> 4.) Another approach?
> 
> If we assume that the target is not running linux, what would be a
> good starting point to work from: m32r?

Hi Andreas,

Glad you liked the application note. There is now another one on writing
an RSP server. I'm hoping to get the key parts incorporated into the
mainstream GDB manual before long, in the meantime it's here:

        http://www.embecosm.com/download/ean4.html

The example I used for the OpenRISC 1000 is bare metal, not Linux (even
though it uses the OpenRISC Linux toolchain), so you could use that as a
starting point.

If you don't intend running GDB on the target, you'll need a remote
connection at some time, so developing the RSP server side makes sense.
The example I used in the application note was talking to a simulator
rather than real hardware, so this is a feasible approach.

HTH,


Jeremy

-- 
Tel:      +44 (1202) 416955
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com

Re: The right way to port GDB to a new architecture

[Doug Evans]

On Tue, Jan 13, 2009 at 7:39 AM, Andreas Olofsson
<andreas.d.olofsson@gmail.com> wrote:
> I have been reading through the GDB documentation and I need some
> advice on the best approach to porting GDB to a new architecture
> before I dive into the porting process..
>
> Describing the architecture doesn't seem too bad and is well described
> in Jeremy Bennett's document "Howto: Porting the GNU debugger".  How
> to actually communicate with the target looks to be more of a
> challenge and there seem to be a number of different approaches.
>
> Possible approaches(we already have bfd, binutils, gcc, and all the
> other stuff ported):
>
> 1.) Use cgen or sid to generate a gdb compliant simulator and link in
> the simulator library.  Since we will need the remote debugging option
> eventually, I am thinking that integrating a cgen based simulator with
> GDB would be extra work and I would like to skip this step if
> possible.

If you don't *need* a simulator, skip it.  Often a simulator is
written because it's an easier vehicle for testing gcc (and gdb to
some extent).

> 2.) Write a stub for the target and use remote serial protocol.  The
> included stubs in the distribution are quite old?  Is this no longer a
> preferred method?

What kind of architecture + o/s?  Is it an embedded system?  Does it
run some o/s?  The stubs are mostly intended for embedded systems
where the device isn't running an o/s, per se, and the application
"owns" the device.  The stub is linked into the application to be
debugged and inserts handlers for various interrupts - not something
one can typically do if running on a typical o/s.  They may be old but
there's not much too them, if your system is similar they could still
be good boilerplate.

>
> 3.) Port gdbserver to the new architecture. Is it a requirement to
> have linux running on the target?  Based on the ports I have seen in
> GDB it would seem to be the case? Why doesn't the ARM have a stub for
> example?  I can't imagine you have to run linux on an arm based device
> to be able use remote GDB?

Porting gdbserver doesn't require linux, linux is just the canonical
example.  gdbserver is for situations where the remote target is
running a multitasking o/s, and it serves as a proxy for gdb.  A lot
of the porting work is similar to the work one must do to port gdb
itself.

You are correct, you don't need linux to debug arm based devices, but
it depends on the device.  For example, if the arm based device is
running linux then a gdbserver port is a reasonable thing to have.
The arm doesn't have a stub only because I suspect no one has
contributed one to the gdb tree.

For reference sake (meaning, here's some data, use it if you get
stuck, but I suspect most of the following won't be helpful) ...
You might also look at rda, http://sourceware.org/rda/, but it's a bit
old too.  There are also stubs in the libgloss part of newlib
(http://sourceware.org/newlib/).    Plus ecos has some gdb stubs
(http://ecos.sourcware.org), although ecos is a big package itself and
extracting the stubs out may be problematic.

>
> 4.) Another approach?
>
> If we assume that the target is not running linux, what would be a
> good starting point to work from: m32r?

m32r is my favorite starting point, but the reasons aren't technical.  :-)
I would pick an architecture that is reasonably similar to yours and
go from there.
What architecture (+ o/s if any) are you porting to?

Re: The right way to port GDB to a new architecture

[Andreas Olofsson]

Hi Doug,

Thanks for the reply.  Here's a follow up question for you (or others).

It sounds like a stub is the way to go for remote debugging. (no OS
planned at this point)

We actually have a functioning cgen generated simulator already but it
is not yet integrated with gdb.  Some of the simulators distributed
with gdb (like the m32r) seem to be generated from cgen as well.  What
would be the effort in creating the necessary interfaces between the
cgen based simulator and gdb.  I am hoping for almost zero.:-)

Andreas



On Tue, Jan 13, 2009 at 2:30 PM, Doug Evans <dje@google.com> wrote:
> On Tue, Jan 13, 2009 at 7:39 AM, Andreas Olofsson
> <andreas.d.olofsson@gmail.com> wrote:
>> I have been reading through the GDB documentation and I need some
>> advice on the best approach to porting GDB to a new architecture
>> before I dive into the porting process..
>>
>> Describing the architecture doesn't seem too bad and is well described
>> in Jeremy Bennett's document "Howto: Porting the GNU debugger".  How
>> to actually communicate with the target looks to be more of a
>> challenge and there seem to be a number of different approaches.
>>
>> Possible approaches(we already have bfd, binutils, gcc, and all the
>> other stuff ported):
>>
>> 1.) Use cgen or sid to generate a gdb compliant simulator and link in
>> the simulator library.  Since we will need the remote debugging option
>> eventually, I am thinking that integrating a cgen based simulator with
>> GDB would be extra work and I would like to skip this step if
>> possible.
>
> If you don't *need* a simulator, skip it.  Often a simulator is
> written because it's an easier vehicle for testing gcc (and gdb to
> some extent).
>
>> 2.) Write a stub for the target and use remote serial protocol.  The
>> included stubs in the distribution are quite old?  Is this no longer a
>> preferred method?
>
> What kind of architecture + o/s?  Is it an embedded system?  Does it
> run some o/s?  The stubs are mostly intended for embedded systems
> where the device isn't running an o/s, per se, and the application
> "owns" the device.  The stub is linked into the application to be
> debugged and inserts handlers for various interrupts - not something
> one can typically do if running on a typical o/s.  They may be old but
> there's not much too them, if your system is similar they could still
> be good boilerplate.
>
>>
>> 3.) Port gdbserver to the new architecture. Is it a requirement to
>> have linux running on the target?  Based on the ports I have seen in
>> GDB it would seem to be the case? Why doesn't the ARM have a stub for
>> example?  I can't imagine you have to run linux on an arm based device
>> to be able use remote GDB?
>
> Porting gdbserver doesn't require linux, linux is just the canonical
> example.  gdbserver is for situations where the remote target is
> running a multitasking o/s, and it serves as a proxy for gdb.  A lot
> of the porting work is similar to the work one must do to port gdb
> itself.
>
> You are correct, you don't need linux to debug arm based devices, but
> it depends on the device.  For example, if the arm based device is
> running linux then a gdbserver port is a reasonable thing to have.
> The arm doesn't have a stub only because I suspect no one has
> contributed one to the gdb tree.
>
> For reference sake (meaning, here's some data, use it if you get
> stuck, but I suspect most of the following won't be helpful) ...
> You might also look at rda, http://sourceware.org/rda/, but it's a bit
> old too.  There are also stubs in the libgloss part of newlib
> (http://sourceware.org/newlib/).    Plus ecos has some gdb stubs
> (http://ecos.sourcware.org), although ecos is a big package itself and
> extracting the stubs out may be problematic.
>
>>
>> 4.) Another approach?
>>
>> If we assume that the target is not running linux, what would be a
>> good starting point to work from: m32r?
>
> m32r is my favorite starting point, but the reasons aren't technical.  :-)
> I would pick an architecture that is reasonably similar to yours and
> go from there.
> What architecture (+ o/s if any) are you porting to?
>

Re: The right way to port GDB to a new architecture

[Doug Evans]

On Wed, Jan 21, 2009 at 1:56 PM, Andreas Olofsson
<andreas.d.olofsson@gmail.com> wrote:
> Hi Doug,
>
> Thanks for the reply.  Here's a follow up question for you (or others).
>
> It sounds like a stub is the way to go for remote debugging. (no OS
> planned at this point)

If there's no OS planned (at least for now) then I'd say a stub is the
way to go.

> We actually have a functioning cgen generated simulator already but it
> is not yet integrated with gdb.  Some of the simulators distributed
> with gdb (like the m32r) seem to be generated from cgen as well.  What
> would be the effort in creating the necessary interfaces between the
> cgen based simulator and gdb.  I am hoping for almost zero.:-)

For reference sake, most gdb simulators use the same (non-isa related)
infrastructure, to varying degrees.  It's in sim/common.

Gluing the simulator to gdb is mostly a matter of cut-n-paste-n-tweak.
 The interface is defined in include/gdb/remote-sim.h.  Several of
those functions are already provided by sim/common.  For the remaining
ones, take an existing simulator (m32r is fine for this purpose) and
ctudy its sim-if.c file (e.g. sim/m32r/sim-if.c).

On the GDB side it's also cut-n-paste-n-tweak.  From gdb/configure.tgt:

m32r*-*-*)
        # Target: Renesas m32r processor
        gdb_target_obs="m32r-tdep.o monitor.o m32r-rom.o dsrec.o \
                        remote-m32r-sdi.o"
        gdb_sim=../sim/m32r/libsim.a
        ;;

The simulator related portion is (of course) the setting of gdb_sim.
Set this to ../sim/<your-cpu>/libsim.a.  Setting this will cause
remote-sim.o to be linked into gdb which will in turn enable the
simulator target from the command line.

Replace m32r-tdep.o with <your-cpu>-tdep.o.  You probably don't need
the equivalent of m32r-rom.o and remote-m32r-sdi.o, so delete those.
dsrec.o is a target independent file for downloading s-records.
Include it if your rom monitor (or whatever) supports s-record
downloads.

>
> Andreas
>
>
>
> On Tue, Jan 13, 2009 at 2:30 PM, Doug Evans <dje@google.com> wrote:
>> On Tue, Jan 13, 2009 at 7:39 AM, Andreas Olofsson
>> <andreas.d.olofsson@gmail.com> wrote:
>>> I have been reading through the GDB documentation and I need some
>>> advice on the best approach to porting GDB to a new architecture
>>> before I dive into the porting process..
>>>
>>> Describing the architecture doesn't seem too bad and is well described
>>> in Jeremy Bennett's document "Howto: Porting the GNU debugger".  How
>>> to actually communicate with the target looks to be more of a
>>> challenge and there seem to be a number of different approaches.
>>>
>>> Possible approaches(we already have bfd, binutils, gcc, and all the
>>> other stuff ported):
>>>
>>> 1.) Use cgen or sid to generate a gdb compliant simulator and link in
>>> the simulator library.  Since we will need the remote debugging option
>>> eventually, I am thinking that integrating a cgen based simulator with
>>> GDB would be extra work and I would like to skip this step if
>>> possible.
>>
>> If you don't *need* a simulator, skip it.  Often a simulator is
>> written because it's an easier vehicle for testing gcc (and gdb to
>> some extent).
>>
>>> 2.) Write a stub for the target and use remote serial protocol.  The
>>> included stubs in the distribution are quite old?  Is this no longer a
>>> preferred method?
>>
>> What kind of architecture + o/s?  Is it an embedded system?  Does it
>> run some o/s?  The stubs are mostly intended for embedded systems
>> where the device isn't running an o/s, per se, and the application
>> "owns" the device.  The stub is linked into the application to be
>> debugged and inserts handlers for various interrupts - not something
>> one can typically do if running on a typical o/s.  They may be old but
>> there's not much too them, if your system is similar they could still
>> be good boilerplate.
>>
>>>
>>> 3.) Port gdbserver to the new architecture. Is it a requirement to
>>> have linux running on the target?  Based on the ports I have seen in
>>> GDB it would seem to be the case? Why doesn't the ARM have a stub for
>>> example?  I can't imagine you have to run linux on an arm based device
>>> to be able use remote GDB?
>>
>> Porting gdbserver doesn't require linux, linux is just the canonical
>> example.  gdbserver is for situations where the remote target is
>> running a multitasking o/s, and it serves as a proxy for gdb.  A lot
>> of the porting work is similar to the work one must do to port gdb
>> itself.
>>
>> You are correct, you don't need linux to debug arm based devices, but
>> it depends on the device.  For example, if the arm based device is
>> running linux then a gdbserver port is a reasonable thing to have.
>> The arm doesn't have a stub only because I suspect no one has
>> contributed one to the gdb tree.
>>
>> For reference sake (meaning, here's some data, use it if you get
>> stuck, but I suspect most of the following won't be helpful) ...
>> You might also look at rda, http://sourceware.org/rda/, but it's a bit
>> old too.  There are also stubs in the libgloss part of newlib
>> (http://sourceware.org/newlib/).    Plus ecos has some gdb stubs
>> (http://ecos.sourcware.org), although ecos is a big package itself and
>> extracting the stubs out may be problematic.
>>
>>>
>>> 4.) Another approach?
>>>
>>> If we assume that the target is not running linux, what would be a
>>> good starting point to work from: m32r?
>>
>> m32r is my favorite starting point, but the reasons aren't technical.  :-)
>> I would pick an architecture that is reasonably similar to yours and
>> go from there.
>> What architecture (+ o/s if any) are you porting to?
>>
>