Bug 63901 - msp430 multilib must distinguish mhwmult
Summary: msp430 multilib must distinguish mhwmult
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-16 03:02 UTC by Peter A. Bigot
Modified: 2014-12-05 21:46 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Built newlib with -mhwmult=none (324 bytes, patch)
2014-11-17 09:16 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter A. Bigot 2014-11-16 03:02:12 UTC
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.
Comment 1 Nick Clifton 2014-11-17 09:16:08 UTC
Created attachment 33997 [details]
Built newlib with -mhwmult=none
Comment 2 Nick Clifton 2014-11-17 09:19:27 UTC
Hi Peter,

  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.

Cheers
  Nick
Comment 3 Peter A. Bigot 2014-11-17 12:07:49 UTC
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.
Comment 4 Nick Clifton 2014-11-21 12:06:10 UTC
Hi Peter,

> 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.

Cheers
  Nick

PS. I have applied the patch to the newlib sources so that at least that part of the problem is resolved for now.
Comment 5 Peter A. Bigot 2014-11-21 13:50:50 UTC
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.