Updating binutils for new MSP430 chips

[Peter Bigot <pab at peoplepowerco dot com>]

Support for TI's MSP430 line of microcontrollers was added to binutils in
the mid 2000s, and is most frequently used with the mspgcc project's patches
to GCC 3.2.3.  I've been maintaining the forked versions used in mspgcc4 for
the last six months, and have been working with Texas Instruments to extend
GNU toolchain support to several chip lines that have been added since then.
I'm now working to bring the mspgcc and mspgcc4 back together and unify the
toolchain.

I've been unable to contact the listed binutils MSP430 maintainer (Dmitry
Diky) at any of the email addresses I've found, and he doesn't appear to be
active in the community.  So I'm planning to proceed with updates.  I'd like
to do this in a way that they can be integrated into the main distribution,
but that's secondary to developing a solution that's maintainable.  What's
there right now doesn't meet that goal.

Currently binutils has two architectures defined for MSP430: EM_MSP430 and
EM_MSP430_OLD.

Mainline binutils has 14 sub-architectures (bfd_mach_msp*/E_MSP430_MACH_*)
and 59 emulations.  The forked binutils has 25 sub-architectures with 100
emulations.

The sub-architectures seem to have no purpose.  Only two are actually used
for something that can't be represented in an emulation (whether a hardware
multiply capability is available), and I think that should be a compiler
multilib feature just as with SIMD instruction support.  I suspect the rest
were intended to avoid problems when linking object files built for two
different chips with different register addresses that were resolved at
assembly time, but in fact there's not even a warning if you actually do
this.

What I would like to do is eliminate all the distinct architectures.
There's one architectural extension that added a few instructions, but I'm
not convinced it warrants a distinct machine type.

Questions:

(a) In what way is the specific machine number used that would cause
problems if I did this?

(b) Should I be concerned about existing object files and libraries that
have the current numbers embedded in them?  (If the machine number is never
used, I think the answer is it won't matter.)

(c) Would eliminating all these machine numbers be an acceptable patch for
mainline binutils?

Next question deals with emulations.  There are currently over 270 chips in
the MSP430 line.  Most of them differ in terms of flash and RAM memory
addresses and sizes, as well as whether certain peripherals are available
(which isn't a concern to binutils).  Historically, the approach has been to
define an emulation for each one of them.

What I'd really like to do is have a file for each chip that defines its
MEMORY section, and possible the physical addresses of the hardware
registers it supports.  Everything else, such as the SECTIONS blocks, should
be close to the same.

I would really like to have a way where, if TI releases a new chip that
requires a different MEMORY command block, a user can add that to a build
command and use the chip without requiring an update to binutils.  From the
linker script perspective it seems like this should be possible with -T, and
possibly other ways.

The killer is the need to list each emulation in ld/Makefile.am.  It's just
unworkable, and clutters binutils.

I'm wondering whether I can get away with a single emulation for
elf32msp430, and require that any invocation of ld include as an input a
script with the appropriate MEMORY command, something like the way elfm64hc*
does for the GENERIC_BOARD variants.

Question:

(a) What linker configuration architecture you would recommend to solve this
problem?

Thanks.

Peter