This is the mail archive of the
mailing list for the GDB project.
Re: 68HC11&68HC12 port for Binutils, Gdb and Gcc
- To: Stephane Carrez <Stephane dot Carrez at worldnet dot fr>, gdb at sourceware dot cygnus dot com
- Subject: Re: 68HC11&68HC12 port for Binutils, Gdb and Gcc
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Fri, 16 Jun 2000 14:12:42 -0700
- References: <394AA4E7.7AC79E6A@worldnet.fr>
On Jun 17, 12:06am, Stephane Carrez wrote:
> Hi Binutils, Gdb, Gcc maintainers, and co,
> At beginning of 1999, I've started to port the Binutils, Gdb and Gcc
> for the Motorola 68HC11 and 68HC12 microcontrollers. The full port
> is completely operational for a long time now.
> I have a letter of assignment for binutils, gdb and gcc but I have none for
> newlib and dejagnu. I can still send you the patches for newlib and dejagnu
> if you like. (available on the web anyway).
> That's all folks, I hope you'll be prepared to receive the patches,
I looked over the gdb portions of your patches that I found at
Overall, the patches look good. Some comments...
- Send your gdb patches to email@example.com.
- When you send us your patches, don't include patches for ChangeLog
comments. Instead, prepend your ChangeLog entries to the front of
the patch. The person integrating your patch will put them in the
ChangeLog just prior to committing them.
- Don't send patches for the configure scripts (or any other files
which are automatically generated.) We do need patches for
configure.in though. (I understand why they're in the patch on your
web page though.)
- It'd be best if you'd generate your patches with respect the latest
development sources. For gdb, information on accessing the CVS
repository may be found at
This will involve a bit of work on your part since it is quite likely
that your 4.18 patches will not apply cleanly to the current source
base. However, you really are the best one to do this work since
you are the one most familiar with your port and you also have the
equipment to test the end result.
- Over time, it would be best if you'd "multi-arch" your target. This
means that most of the stuff defined via macros in tm-m68hc11.h
will get moved to m68hc11-tdep.c and will be defined as functions
instead. You will also add m68hc11_gdbarch_init() (or somesuch) to
your tdep.c file to set up access to these functions through the
multi-arch framework. For examples of multi-arched code, take a
look at d10v-tdep.c, mips-tdep.c, or ia64-tdep.c.
I think it'd be okay though if you'd submit your code in it's
present non-multiarched form, get it into the repository, and then
work on multi-arching it. (We can help you with that, but it'll be
easier if your code is in place first.)
- I noticed that support for calling inferior functions (all of the
call dummy stuff) isn't finished yet. That's okay... but when you
get around to it, I suggest you use the generic dummy frames
machinery. (You will be amazed at how much easier this is to use
than the old mechanism.) Search for the "GENERIC DUMMY FRAMES"
comment in blockframe.c for more information.