Re: 68HC11&68HC12 port for Binutils, Gdb and Gcc

[Kevin Buettner <kevinb at cygnus dot com>]

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,

Hi Stephane,

I looked over the gdb portions of your patches that I found at

  http://home.worldnet.fr/~stcarrez/snapshots/gdb-4.18-m68hc11-20000416.diffs.gz

Overall, the patches look good.  Some comments...

 - Send your gdb patches to gdb-patches@sourceware.cygnus.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

	http://sourceware.cygnus.com/gdb/#download

   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.

Kevin