This is the mail archive of the
mailing list for the GDB project.
The right way to port GDB to a new architecture
- From: "Andreas Olofsson" <andreas dot d dot olofsson at gmail dot com>
- To: gdb at sourceware dot org
- Date: Tue, 13 Jan 2009 10:39:59 -0500
- Subject: The right way to port GDB to a new architecture
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
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
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?