This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]