From: Peter Bigot <pabigot@us...> - 2012-11-26 12:50:24
On Mon, Nov 26, 2012 at 5:05 AM, Anton Korobeynikov <anton@...
> > Clang seems to emit a global alias for every ISR (called
> > When linking a binary using mspgcc, the linker seems to expect the
> vectors to
> > be called __isr_<number>. To make the linker pick up the vectors, I
> > add something like this to my linker script: "__isr_9 = vector_fff2;" It
> > cumbersome to have to do this manually for every ISR.
> > So my question is: is there a better way to make the linker pick up the
> > vectors emitted by clang?
> This seems to be something that changed in msp430-ld. Previously
> linker definitely expected to see vector_* stuff. Feel free to change
> alias :)
FWIW, current mspgcc-based binutils (which llvm may use) does not lay out
the vectors. The vector table is in sector .vectors and should be composed
mspgcc does this with a crt0ivbl.S assembly file that expects symbols with
names __isr_0 through __isr_63. 16, 32, and 64-entry versions of the table
are supplied to support the capabilities of the target MCU. Also, for MCUs
with more than 32 vector entries the first 32 are replaced by __vte_0
through __vte_31. This is to avoid placing default vector handlers in
places where newer chips are putting JTAG and BSL passwords; see
related discussion. __vte_0 values may be overridden at link time as
the default 0xFFFF is PROVIDEd by the linker script.
LLVM users should be aware that TI has hired Red Hat to re-do the GNU
toolchain support for MSP430 and push it upstream, which could not be done
with mspgcc due to IP issues from past contributions over the last ten
years. I understand that Red Hat and TI were somehow unaware of the extent
of binutils enhancements done to support mspgcc capabilities, including the
changes to how vectors are managed. It is likely the interface will change
again when they decide how they want to approach the issue. See the thread