The msp430 target has an option -mhwmult that is used to select among emulated and hardware-assisted multiplication capabilities. Because this option does not contribute to the selection of multilib an application built for -mhwmult=f5series linking with newlib will reference a strtoul implementation that is built for a default -mhwmult=16. Since the 16-bit multiply peripheral does not exist on an F5 series MCU, the processor will fault.
Created attachment 33997 [details]
Built newlib with -mhwmult=none
The whole hardware multiply selection thing is a bit of a mess...
The uploaded patch should resolve the problem for now by building newlib with software multiply enabled.
In the long term we ought to work out a way to enable multilib versions of newlib based upon the hardware multiply supported. The problem with that is that multilib selection is based solely upon the command line options used which means that a list of all known MSP430 MCU types would probably have to be built into the specs - a bad idea that will fail as soon as a new MCU type is created.
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 \
" %(msp430_cpu)" \
" %(msp430_mpy)" \
" %(msp430_ivcnt)" \
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.
> 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.
Could the tool that converted the CSV file into a spec fragment be altered so that it produces the relevent -mhwmult= option based upon an MCU input ? Ie would it be possible to provide the users with a tool that takes an MCU name, reads in the CSV file and outputs the correct -mhwmult option ? Somthing like:
msp430-elf-gcc `gen-hwmult-opt -mmcu=foo`
If the tool was stand-alone then it would not need to be updated when the CSV file changes, and it could work with any CSV file, old or new.
PS. I have applied the patch to the newlib sources so that at least that part of the problem is resolved for now.
Yes, that could work. msp430mcu in mspgcc days did a lot more than specs fragments; if interested see the relevant material (BSD-3-Clause) is in the msp430mcu repository at: https://sourceforge.net/p/mspgcc/msp430mcu/ci/master/tree/
I still prefer the specs approach because it's nicer for the users. But I'm coming to accept the alternative you suggest.
So yes: remove -mmcu interpretation from gcc and require people to provide all the relevant specifications explicitly (defaulting to -mcpu=430 and -mhwmult=none). Implement a proper multilib demux based on both -mcpu and -mhwmult, rather than making all libc users take on the overhead of software multiply routines. (Ick.)
Providing a tool that identifies the right -m* options for a specific MCU is TI's responsibility. They already do part of the job by providing the device-specific headers and linker scripts (maybe someday as versioned releases). Adding an msp430-elf-mcu-options script should be less than a day's effort for them.