https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901
--- Comment #3 from Peter A. Bigot <pab at pabigot dot com> --- But it's already bad, because you have the list of MCUs hard-coded into the compiler source, which is a lot worse than doing through the specs. It's really unfortunate that somebody decided to exclude me from being involved with this port, since all these problems were handled by mspgcc. Without risking whatever fear of IP contamination might have led to that decision: In mspgcc, TI provided a CSV file that listed every device along with all its characteristics. This is still present in the GCC header bundle TI provides. This in turn was processed to produce a specs fragment that provided rules to default all the -m* flags from a specific -mmcu= value. The msp430.h header then defined: /* On startup read the spec file that translates known MCUs into * device-specific flags (note: this is an msp430 extension to the * upstream driver). Also ensure we have -mcpu, -mmpy, and -mivcnt * configurations derived from the mcu. */ #define DRIVER_SELF_SPECS \ "%:include-noerr(msp430mcu.spec)" \ " %(msp430_cpu)" \ " %(msp430_mpy)" \ " %(msp430_ivcnt)" \ " %(msp430_memmodel)" along with other changes to propagate the information to the various compiler, assembler, and linker phases. With this the set of supported MCUs is completely decoupled from the toolchain, allowing all new devices to be supported by updating whatever package provides the headers and linker scripts (which msp430-elf already requires) by adding to that a replacement spec fragment.
