This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
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?
>>
>