Hi Keith,
On 9/8/26 2:45 PM, Keith Packard wrote:
Thanks for adding msp430 support to binutils-embedded. I noticed that you used
msp430-unknown-elf as the triplet. It's my understanding that that expands to
msp430-unknown-unknown-elf.
"expands"? I'm not sure what would expand the name?
The full "triplet" has four elements:
arch-vendor-system-environment
Almost any of them may be omitted and the absent values will be filled in
(usually
with "unknown"). Unfortunately, GCC does not do a particularly-good job at
documenting "triplets" (the best we get is [1]; cf. [2]).
I've been using msp430-elf, following arch [1]. As
I understand it that expands to msp430-none-elf -> msp430-unknown-none-elf.
Rust also uses msp430-none-elf [2]. Any reason why you went with -unknown- over
It could be msp430-none-elf instead, but that means 'no' OS, while
'unknown' means the underlying OS isn't specified, which seems more
accurate as this toolchain can be used with Zephyr, RIOT or FreeRTOS
quite effectively.
That field is only for OSs with privilege separation (e.g. an ABI). Bare-metal
RTOSs
are effectively libraries and usually do not require toolchain support. In
cases where
they do (such as if the RTOS supports loadable modules), then they go in the
final
position of the triplet (e.g. you could have arm-none-vxworks).
In particular, clang explicitly documents [3] that "none" should be used for
bare-metal systems.
--Sean
[1] https://gcc.gnu.org/install/specific.html
| Note that this list of install notes is not a list of supported hosts or
| targets. Not all supported hosts and targets are listed here, only the ones
| that require host-specific or target-specific information have to.
[2] https://wg21.link/p1864r0 (never accepted, but attempts to document current
practice)
[3] https://clang.llvm.org/docs/CrossCompilation.html#target-triple
