A project dedicated to building LLVM toolchain for 32-bit Arm embedded targets.

License: Apache License 2.0

Shell 2.01% C 0.36% C++ 2.26% CMake 72.57% Python 22.79%

llvm-embedded-toolchain-for-arm's Introduction

LLVM Embedded Toolchain for Arm

This repository contains build scripts and auxiliary material for building a bare-metal LLVM based toolchain targeting Arm based on:

clang + llvm
lld
libc++abi
libc++
compiler-rt
picolibc, or optionally newlib

Goal

The goal is to provide an LLVM based bare-metal toolchain that can target the Arm architecture family from Armv6-M and newer. The toolchain follows the ABI for the Arm Architecture and attempts to provide typical features needed for embedded and realtime operating systems.

Supported architectures

Armv6-M
Armv7-M
Armv7E-M
Armv8-M Mainline and Baseline
Armv8.1-M Mainline and Baseline
Armv4T (experimental)
Armv5TE (experimental)
Armv6 (experimental, using the Armv5TE library variant)
AArch64 armv8.0 (experimental)

C++ support

C++ is partially supported with the use of libc++ and libc++abi from LLVM. Features that are not supported include:

Multithreading

LLVM Embedded Toolchain for Arm uses the unstable libc++ ABI version. This ABI uses all the latest libc++ improvements and bugfixes, but may result in link errors when linking against objects compiled against older versions of the ABI. For more information see https://libcxx.llvm.org/DesignDocs/ABIVersioning.html.

Components

The LLVM Embedded Toolchain for Arm relies on the following upstream components

Component	Link
LLVM	https://github.com/llvm/llvm-project
picolibc	https://github.com/picolibc/picolibc

License

Content of this repository is licensed under Apache-2.0. See LICENSE.txt.

The resulting binaries are covered under their respective open source licenses, see component links above.

Host platforms

LLVM Embedded Toolchain for Arm is built and tested on Ubuntu 18.04 LTS.

The Windows version is built on Windows Server 2019 and lightly tested on Windows 10.

Building on macOS is functional for x86_64 and Apple Silicon.

Binary packages are provided for major LLVM releases for Linux and Windows.

Getting started

Download a release of the toolchain for your platform from Github releases and extract the archive into an arbitrary directory.

Using the toolchain

Note: If you are using the toolchain in a shared environment with untrusted input, make sure it is sufficiently sandboxed.

To use the toolchain, on the command line you need to provide the following options:

The target triple.
The FPU to use.
Disabling/enabling C++ exceptions and RTTI.
The C runtime library: either crt0 or crt0-semihost.
The semihosting library, if using crt0-semihost.
A linker script specified with -T. Default picolibcpp.ld and picolibc.ld scripts are provided and can be used directly or included from a custom linker script.

For example:

$ PATH=<install-dir>/LLVMEmbeddedToolchainForArm-<revision>/bin:$PATH
$ clang \
--target=armv6m-none-eabi \
-mfpu=none \
-fno-exceptions \
-fno-rtti \
-lcrt0-semihost \
-lsemihost \
-T picolibc.ld \
-o example example.c

clang's multilib system will automatically select an appropriate set of libraries based on your compile flags. clang will emit a warning if no appropriate set of libraries can be found.

To display the directory selected by the multilib system, add the flag -print-multi-directory to your clang command line options.

To display all available multilibs run clang with the flag -print-multi-lib and a target triple like --target=aarch64-none-elf or --target=arm-none-eabi.

It's possible that clang will choose a set of libraries that are not the ones you want to use. In this case you can bypass the multilib system by providing a --sysroot option specifying the directory containing the include and lib directories of the libraries you want to use. For example:

$ clang \
--sysroot=<install-dir>/LLVMEmbeddedToolchainForArm-<revision>/lib/clang-runtimes/arm-none-eabi/armv6m_soft_nofp \
--target=armv6m-none-eabi \
-mfpu=none \
-fno-exceptions \
-fno-rtti \
-lcrt0-semihost \
-lsemihost \
-T picolibc.ld \
-o example example.c

The FPU selection can be skipped, but it is not recommended to as the defaults are different to GCC ones.

Binary releases of the LLVM Embedded Toolchain for Arm are based on release branches of the upstream LLVM Project, thus can safely be used with all tools provided by LLVM releases of matching version.

See Migrating from Arm GNU Toolchain and Experimental newlib support for advice on using LLVM Embedded Toolchain for Arm with existing projects relying on the Arm GNU Toolchain.

Note: picolibc provides excellent support for Arm GNU Toolchain, so projects that require using both Arm GNU Toolchain and LLVM Embedded Toolchain for Arm can choose either picolibc or newlib.

Building from source

LLVM Embedded Toolchain for Arm is an open source project and thus can be built from source. Please see the Building from source guide for detailed instructions.

Providing feedback and reporting issues

Please raise an issue via Github issues.

Contributions and Pull Requests

Please see the Contribution Guide for details.

llvm-embedded-toolchain-for-arm's People

Contributors

Stargazers

Watchers

Forkers

galak mfkiwl yongqian10 babyge statham-arm fanghuaqi davemgreen linux-bytes vhscampos miyuki stuij kiliankilmister global-localhost global19 global19-atlassian-net simpal01 danhag01 chommik yazdandeli guozhanxin kbeyls trass3r qpc-database sirokujira atomicdog jordanresearch mbrossard lulle2007200 denji danielkristofkiss jevinskie dothanthitiendiettiende qshan vsydoruk lz3450 aquini xiaoxiang781216 matchrom zipper1956 isabella232 mcusec mplatings adfernandes hustwbxs mblenczewski-arm ulrikhjort mtomczykmobica voltur01 goodship1 rockdreamer pwprzybyla driveraid mean00 gmh5225 rgrr np22-jpg smithp35 dcandler weileiyuan kebrahimpour domin144 amilendra tannewt kerakov tomxi1997 bkavcaduhq amazingplace 32bitmicro goodluck14 zz-fz-john lqs66 yyzqll yroux solutionsexcite edmundmarcia liruncong sivan-shani brugarolas laur59 vrukesh

llvm-embedded-toolchain-for-arm's Issues

LLVM released 14.0.0 one month ago, when do you plan to release 14.0.0 binary?

Add libraries or new passes to the installation

I'm not sure if I understand it correctly.

I want to write a new pass that works on embedded devices, which requires the opt tool to load the pass.
For testing, I can simply run make directly inside the LLVM repo and use tools inside the build folder.
And this is actually what LLVM itself supports.

For other reasons, I need to cross-compile the toolchain and make it work on the Windows system.
Then after building this toolchain, the install directory does not contain the tools or libraries that LLVM provides.
I figured out how to add tools to the install/bin folder, such as opt and llvm-link, by adding new components (dist_comps) inside the make.py file.

But I don't know how to add libraries to load passes successfully.
Could you please give me some suggestions? Forgive me if I miss any important instructions.

I very much appreciate your work on such a wonderful job.

Thank you so much.

patch filename in CmakeList.txt

Hi all!
First thanks for the work bringing LLVM to embedded ARM processors.
CMakeList.txt refers to a patch file patches/llvm-project/0002-libc-Add-check-for-building-with-picolibc.patch but in the files availables in patches/llvm-project are:

0001-Fix-llvm-test-CodeGen-ARM-build-attributes.ll-test.patch Unchanged
0002-Add-check-for-building-with-picolibc.patch Unchanged
0003-Run-picolibc-tests-with-qemu.patch Unchanged
0004-xfail-two-remaining-libcxx-with-picolibc-tests.patch Unchanged

Provide support for newlib nano

Hello,

First of all , it is great to see LLVM based embedded toolchain is coming for ARM Cortex M family. Thank you guys for the effort.

Now to the issue, contrary to the ARM GNU Embedded toolchain there is no "nano" flavored C library in the output directory and the released binary. There is, however, the nano.specs file present which is a bit odd. Is there a plan to compile newlib with "nano" configuration?

Thank you,
Volod

Provide multilib support

Multilib toolchains contain multiple sysroot, each having a version of the target libraries for different architecture/ABI variants that are selected based on the target and other command line options.

Now users have to specify --config option to explicitly select the library variant.

how to use static base register r9?

I want to compile a source code with PIC + static base r9 register.
For GCC, I use commands below:
`
PS Z:\elfloader> cat main.c
static int __local_cnt = 1;
static int __local_idx;
extern int printf(const char *format, ...);
int main(int argc, char *argv[])
{
__local_cnt++;
__local_idx = 1;
printf("test: %d %d\n", __local_cnt, __local_idx);
return 0;
}
PS Z:\elfloader> arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -fPIC -msingle-pic-base -mpic-register=r9 -mno-pic-data-is-text-relative -Wall -g -O2 -c main.c -o main.o
PS Z:\elfloader> arm-none-eabi-gcc -shared -fPIC -msingle-pic-base -mpic-register=r9 -mno-pic-data-is-text-relative -nostdlib -o main.elf main.o
PS Z:\elfloader> arm-none-eabi-objdump -S main.elf

main.elf: file format elf32-littlearm

Disassembly of section .plt:

0000014c <.plt>:
14c: b500 push {lr}
14e: f8df e008 ldr.w lr, [pc, #8] ; 158 <.plt+0xc>
152: 44fe add lr, pc
154: f85e ff08 ldr.w pc, [lr, #8]!
158: 000100dc .word 0x000100dc

0000015c printf@plt:
15c: f240 0cd8 movw ip, #216 ; 0xd8
160: f2c0 0c01 movt ip, #1
164: 44fc add ip, pc
166: f8dc f000 ldr.w pc, [ip]
16a: e7fc b.n 166 <printf@plt+0xa>

Disassembly of section .text:

0000016c

:
static int __local_cnt = 1;
static int __local_idx;
extern int printf(const char *format, ...);
int main(int argc, char *argv[])
{
16c: b508 push {r3, lr}
__local_cnt++;
16e: 4a07 ldr r2, [pc, #28] ; (18c <main+0x20>)
__local_idx = 1;
printf("test: %d %d\n", __local_cnt, __local_idx);
170: 4b07 ldr r3, [pc, #28] ; (190 <main+0x24>)
__local_cnt++;
172: f859 0002 ldr.w r0, [r9, r2]
176: 6801 ldr r1, [r0, #0]
printf("test: %d %d\n", __local_cnt, __local_idx);
178: 2201 movs r2, #1
__local_cnt++;
17a: 4411 add r1, r2
17c: 6001 str r1, [r0, #0]
printf("test: %d %d\n", __local_cnt, __local_idx);
17e: f859 0003 ldr.w r0, [r9, r3]
182: f7ff ffeb bl 15c printf@plt
return 0;
186: 2000 movs r0, #0
188: bd08 pop {r3, pc}
18a: bf00 nop
18c: 00000014 .word 0x00000014
190: 00000010 .word 0x00000010
`

But there is BUG in arm-none-eabi-gcc while processing code in plt sections, whick still use PC + offset instead of R9 to obtain GOT address.

For llvm, it seems the options are different:
PS Z:\elfloader> E:\Software\armllvm\bin\clang.exe --config armv6m_soft_nofp_nosys -mcpu=cortex-m4 -mthumb -fPIC -msingle-pic-base -mpic-register=r9 -mno-pic-data-is-text-relative -Wall -g -O2 -c main.c -o main.o clang: error: unknown argument: '-msingle-pic-base' clang: error: unknown argument: '-mpic-register=r9' clang: error: unknown argument: '-mno-pic-data-is-text-relative'
It seems -nostdlib and -shared are not available in llvm too?

I checked the docs here: https://developer.arm.com/documentation/100748/0612.
But can not find the corresponding options.

Support Zephyr Project as an ARM official toolchain

Zephyr Project is becoming more and more popular in the RTOS area. For ARM Cortex architecture, they have their own toolchain/SDK based on GCC. And the ARM maintained arm-none-eabi-gcc also works perfectly with this project.

They have discussed supporting LLVM a few years ago, but seems there's not any progress yet! I think the main reason is that there's no official LLVM toolchain maintained for ARM Cortex before.

Since you are supporting LLVM officially, is there any schedule to support these modern RTOS? Thank you : )

I think combining LLVM + modern RTOS makes it easier to use modern languages on microcontrollers such as Rust and Swift, they both are based on LLVM : ) This would help application development on microcontrollers a lot!

Plan to provide support Single-precision(-mfpu=fpv5-sp-d16) on Cortex-M33

Hello ARM,

I've been integrating the Clang compiler recently, seems Clang Tool chain only provide the double-precision(-mfpu=fpv5-d16) library in the configuration of armv8-m.main(Cortex-M33), Does ARM plan to provide support for multi libraries with different configurations?

$ clang  --config armv8m.main_hard_fp_nosys --print-file-name libclang_rt.builtins-armv8m.main.a
lib/clang-runtimes/armv8m.main_hard_fp/lib/libclang_rt.builtins-armv8m.main.a

00000000 <__divdc3>:
   0: e92d 43f0   stmdb sp!, {r4, r5, r6, r7, r8, r9, lr}
...
  16: eeb0 0bc3   vabs.f64  d0, d3
  1a: eeb0 1bc4   vabs.f64  d1, d4
  1e: eeb4 1b40   vcmp.f64  d1, d0
...

Support for softfp?

Seems like the packaged versions of standard library are either hard or soft, there doesn't seem to be any packaged libraries for softfp variants. Is this deliberate or was simply missed out?

ARM ASM inline error

I have asm code inlined in a .h file containing the line:
__asm volatile ("ldrb.w r1,[r1, #-2]");
When compiling

clang --target=armv7e-none-eabi -mthumb -mcpu=cortex-m7  -c -o syscallDispatcher.o -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-sp-d16 -mthumb -Wall -g3 -pedantic -ansi -Os -Wconversion -Wempty-body -Wignored-qualifiers -Wmissing-field-initializers -Wsign-compare -Wtype-limits -Wuninitialized -Wunused-but-set-parameter -Wshadow -Wpointer-arith -Wunreachable-code -Wnonnull -Winit-self -Wmissing-braces -Wparentheses -Wswitch -Wenum-conversion -Wchar-subscripts -Wswitch-default -Wcast-align -Wtrigraphs -Wcast-qual -Wformat -Wcast-qual -Wcomment -Wformat-security -Wsequence-point -Wno-main -Woverride-init -Wstrict-prototypes -Wimplicit -std=c11  -Wc++-compat Cores/CORTEX_M7/Runtime/syscallDispatcher.c

Cores/CORTEX_M7/Runtime/syscallDispatcher.c:74:2: error: invalid operand for instruction
        SVC_DISPATCHER;
        ^
Cores/CORTEX_M7/macros/macros_core.h:384:25: note: expanded from macro 'SVC_DISPATCHER'
                            __asm volatile ("ldrb.w         r1,[r1, #-2]"); \
                                            ^
<inline asm>:1:13: note: instantiated into assembly here
        ldrb.w          r1,[r1, #-2]

If instead of #-2 one use #2, there is no error. This seems to indicate that the LLVM asm implantation for ARM does not accept negative offset, which is incorrect according to page 3-27 of the document ARM DUI 0646A (ID042815) ARM Cortex-M7 Devices Generic User Guide.

When compiled with arm-none-eabi-gcc no problems occur.

[CMake] Building fails on Arch Linux due to variable UNIX not set

Hi all!
I manually cloned the LLVM and picolibc repos as instructed, because I need to modify the LLVM source code. However, when compiling the project, CMake complains:

[22/245] Running utility command for compiler_rt_aarch64
[23/245] Performing configure step for 'libcxx_libcxxabi_libunwind_aarch64'
-- Could NOT find LLVM (missing: LLVM_DIR)
-- Could NOT find Clang (missing: Clang_DIR)
CMake Error at /home/alessandro/tesi/LLVM-embedded-toolchain-for-Arm/repos/llvm-project/llvm/cmake/modules/HandleLLVMOptions.cmake:150 (MESSAGE):
  Unable to determine platform
Call Stack (most recent call first):
  CMakeLists.txt:157 (include)

The referenced file is:

if(WIN32)
  set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
  if(CYGWIN)
    set(LLVM_ON_WIN32 0)
    set(LLVM_ON_UNIX 1)
  else(CYGWIN)
    set(LLVM_ON_WIN32 1)
    set(LLVM_ON_UNIX 0)
  endif(CYGWIN)
else(WIN32)
  if(FUCHSIA OR UNIX)
    set(LLVM_ON_WIN32 0)
    set(LLVM_ON_UNIX 1)
    if(APPLE OR ${CMAKE_SYSTEM_NAME} MATCHES "AIX")
      set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
    else()
      set(LLVM_HAVE_LINK_VERSION_SCRIPT 1)
    endif()
  else(FUCHSIA OR UNIX)
    MESSAGE(SEND_ERROR "Unable to determine platform") // <----- HERE
  endif(FUCHSIA OR UNIX)
endif(WIN32)

So apparently CMake doesn't recognize my system as UNIX. Moreover,
I've tried adding these lines

message(STATUS "Using LLVM on: ${CMAKE_SYSTEM_NAME}")
set(UNIX TRUE)

at the beginning of the CMakeLists.txt, but the first prints blank, and the second seems not to have effect (even on the list of variables printed using -LH. I also tried to invoke CMake using -DUNIX=True but with no effect.

What can I do?

Thanks!

Provide support for Armv7 and Armv8 A-profile and R-profile

C++ constructors are not run in static initialisation

#include <cstdio>
#include <vector>

class Base {
  private:
    std::vector<int> v;

  public:
    Base() {
      this->v.push_back(1);
      this->v.push_back(2);
      this->v.push_back(3);
    }

    void foo() const {
      printf("Size: %d\n", v.size());
      for (int e: v) {
        printf("%d\n", e);
      }
    }
};

Base b;

int main() {
  b.foo();
}

Output is: "Size: 0".
It seems that C++ constructors are not run in static initialisation.

No clangd support?

Build failure on macOS: FAILED: lib/libunwind.a

It's not clear to me exactly what's gone wrong here. It fails on ninja llvm-toolchain:

[312/921] Linking C static library lib/libunwind.a
FAILED: lib/libunwind.a 
: && "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool" -static -no_warning_for_no_symbols -o lib/libunwind.a  libunwind/src/CMakeFiles/unwind_static_objects.dir/libunwind.cpp.o libunwind/src/CMakeFiles/unwind_static_objects.dir/Unwind-EHABI.cpp.o libunwind/src/CMakeFiles/unwind_static_objects.dir/Unwind-seh.cpp.o libunwind/src/CMakeFiles/unwind_static_objects.dir/Unwind_AppleExtras.cpp.o libunwind/src/CMakeFiles/unwind_static_objects.dir/UnwindLevel1.c.o libunwind/src/CMakeFiles/unwind_static_objects.dir/UnwindLevel1-gcc-ext.c.o libunwind/src/CMakeFiles/unwind_static_objects.dir/Unwind-sjlj.c.o libunwind/src/CMakeFiles/unwind_static_objects.dir/UnwindRegistersRestore.S.o libunwind/src/CMakeFiles/unwind_static_objects.dir/UnwindRegistersSave.S.o && :
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: libunwind/src/CMakeFiles/unwind_static_objects.dir/libunwind.cpp.o is not an object file (not allowed in a library)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: libunwind/src/CMakeFiles/unwind_static_objects.dir/Unwind-EHABI.cpp.o is not an object file (not allowed in a library)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: libunwind/src/CMakeFiles/unwind_static_objects.dir/Unwind-seh.cpp.o is not an object file (not allowed in a library)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: libunwind/src/CMakeFiles/unwind_static_objects.dir/Unwind_AppleExtras.cpp.o is not an object file (not allowed in a library)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: libunwind/src/CMakeFiles/unwind_static_objects.dir/UnwindLevel1.c.o is not an object file (not allowed in a library)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: libunwind/src/CMakeFiles/unwind_static_objects.dir/UnwindLevel1-gcc-ext.c.o is not an object file (not allowed in a library)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: libunwind/src/CMakeFiles/unwind_static_objects.dir/Unwind-sjlj.c.o is not an object file (not allowed in a library)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: libunwind/src/CMakeFiles/unwind_static_objects.dir/UnwindRegistersRestore.S.o is not an object file (not allowed in a library)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: libunwind/src/CMakeFiles/unwind_static_objects.dir/UnwindRegistersSave.S.o is not an object file (not allowed in a library)
ninja: build stopped: subcommand failed.
FAILED: runtimes/aarch64/src/runtimes_aarch64-stamp/runtimes_aarch64-build /Users/rmann/Projects/Personal/EmbeddedSwift/LLVM-embedded-toolchain-for-Arm/build/runtimes/aarch64/src/runtimes_aarch64-stamp/runtimes_aarch64-build 
cd /Users/rmann/Projects/Personal/EmbeddedSwift/LLVM-embedded-toolchain-for-Arm/build/runtimes/aarch64/src/runtimes_aarch64-build && /opt/homebrew/Cellar/cmake/3.25.1/bin/cmake --build .
ninja: build stopped: subcommand failed.

macOS: 13.1
Xcode: 14.1

$ clang --version
Homebrew clang version 15.0.6
Target: arm64-apple-darwin22.2.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin

I also get a number of CMake warnings like

CMake Warning:
  Manually-specified variables were not used by the project:

    LIBCXX_ENABLE_DEBUG_MODE_SUPPORT
    LLVM_CCACHE_BUILD

Error when compiling micro-ecc

I build micro-ecc with the following parameters:
-std=c11 --config armv6m_soft_nofp_nosys.cfg -mno-unaligned-access -fshort-enums -fshort-wchar -g -ffunction-sections -fdata-sections -faapcs-bitfield-width -fno-common -Wall -Os

It comes out that

Could you add clang-tidy to the toolchain, please?

This comes bundled with the releases of the llvm-project and had been convenient to get bundled here as well.

Provide a flavor with exception support

Hello!

First, I am really excited that this project is being developed, since other developers might not have to cross-compile the compiler runtime, libc, libc++, ... on their own. Moreover, having an alternative to the ARM GNU Toolchain based on LLVM is so cool!

However, I cross-compile firmware with the exceptions enabled, but the main page lists the exception handling feature as not supported. The ARM GNU Toolchain provided c++ libraries in nano and "normal" flavor. Linking to the latter flavor, exceptions were handled correctly.

Could this project provide something similar? The toolchain could bundle libc++ ABI library in nano and exceptions flavors.

printf() doesn't work with floating-point values

The following example:

#include <stdio.h>

int main()
{
  float f = 1.0f;
  printf("%f", f);
  return 0;
}

results in the following error with LLVM bare-metal version 0.1:

$ clang --config armv6m-none-eabi_rdimon -g -o printf *.c
$ qemu-arm -cpu cortex-m0 printf
assertion "Balloc succeeded" failed: file "/home/voltur01/work/bare-metal-llvm/from-github/LLVM-embedded-toolchain-for-Arm/repos-0.1/newlib.git/newlib/libc/stdlib/dtoa.c", line 426

printing, e.g. integers, works just fine.

build.py relies on tar options specific to GNU tar

macOS X uses bsdtar 3.3.2 which does not support the --owner option (it is a GNU tar option). Because of this build.py fails on macOS:

ERROR: Command failed with return code 1, stderr:
tar: Option --owner=root is not supported

bsdtar uses different names for the options to set owner and group, --uname and --gname respectively.

Cannot compile simple c++ program

Hi.
I am trying to compile simple c++ program with semihosting without success. My cmdline is:

clang++ -o hello hello.cpp --config aarch64_semihost.cfg -T picolibcpp.ld -fuse-ld=lld

The program is:

#include <iostream>
using namespace std;

int main(int argc, char *argv[])
{
    cout << "Hello world!" << endl;
    return 0;
}

Since few commits ago it localization was not enabled so iostream was not usable at all. After localization was enabled I got some errors regarding wide characters support in iostream.

After changing -DLIBCXX_ENABLE_WIDE_CHARACTERS=OFF to -DLIBCXX_ENABLE_WIDE_CHARACTERS=ON in CMakeLists.txt I am getting the following errors:

clang++ -o hello hello.cpp --config aarch64_semihost.cfg -T picolibcpp.ld -fuse-ld=lld
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 948 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 1756 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 1764 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 1824 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 1956 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 2124 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 2304 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 2472 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 2648 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 2816 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 2912 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 4048 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 4144 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 4236 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 4332 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 4424 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 4520 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 4612 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 4808 bytes
ld.lld: error: section '.text' will not fit in region 'flash': overflowed by 5032 bytes
ld.lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)
clang-16: error: ld.lld command failed with exit code 1 (use -v to see invocation)

Releases page is empty

README.md says:

Download a release of the toolchain for your platform from Github releases and extract the archive into an arbitrary directory.

However, when clicking the link:

There aren’t any releases here

Windows sample build has outdated config filenames

After the multilib support introduction, configuration files have a different name that follow library variants.

make.bat files must be updated accordingly.

Support for MVE and float-abi=hard for Cortex M85

Using -mcpu=cortex-m85 -mfloat-abi=hard when compiling I am getting an error that instructions vsub.f32 and vfma.f32 require mve.fp. By passing -v flag to clang, I can see the triple selected is -triple thumbv8.1m.main-none-unknown-eabihf.

I haven't been able to figure out the right combination of arguments to enable FPU and MVE.

If I run clang --target=arm-none-eabi -mcpu=cortex-m85 -mfloat-abi=hard -print-multi-lib | grep mve, I get the following results

arm-none-eabi/armv8.1m.main_soft_nofp_nomve;@-target=thumbv8.1m.main-none-unknown-eabi@mfpu=none
arm-none-eabi/armv8.1m.main_hard_nofp_mve;@-target=thumbv8.1m.main-none-unknown-eabihf@march=thumbv8.1m.main+dsp+mve@mfpu=none

But If I run arm-none-eabi-gcc -mcpu=cortex-m85 -mfloat-abi=hard -print-multi-lib | grep mve, I get the following results which seem to indicate MVE and float-abi=hard should be compatible.

thumb/v8.1-m.main+mve/hard;@mthumb@march=armv8.1-m.main+mve@mfloat-abi=hard
thumb/v8.1-m.main+pacbti+mve/bp/hard;@mthumb@march=armv8.1-m.main+pacbti+mve@mbranch-protection=standard@mfloat-abi=hard

Is what I am doing not supported or am I not doing it correctly?

`pylint` gives gives warnings

I checked out the HEAD (15e8c69) of main and ran pylint as suggested in the README:

$ pylint --rcfile=scripts/.pylintrc scripts
************* Module make
scripts/make.py:607:4: C0116: Missing function or method docstring (missing-function-docstring)
************* Module repos
scripts/repos.py:162:0: C0330: Wrong hanging indentation (remove 2 spaces).
              repo, branch_str, status['SHA1'], status['Dirty']))
            | ^ (bad-continuation)
scripts/repos.py:26:0: E0401: Unable to import 'git' (import-error)
************* Module build
scripts/build.py:60:47: C0326: Exactly one space required after comma
    parser.add_argument('--build-dir', type=str,  metavar='PATH',
                                               ^ (bad-whitespace)
scripts/build.py:146:33: C0326: Exactly one space required after comma
    parser.add_argument('actions',  nargs=argparse.REMAINDER,
                                 ^ (bad-whitespace)
************* Module config
scripts/config.py:162:42: C0326: Exactly one space required after comma
        self.name = '{}_{}_{}'.format(arch,  float_abi.value, name_suffix)
                                          ^ (bad-whitespace)
scripts/config.py:227:0: C0330: Wrong continued indentation (remove 3 spaces).
                                  action != Action.TEST)
                               |  ^ (bad-continuation)
scripts/config.py:226:34: R1714: Consider merging these comparisons with "in" to 'action not in (Action.ALL, Action.TEST)' (consider-using-in)
------------------------------------------------------------------
Your code has been rated at 9.89/10 (previous run: 9.89/10, +0.00)

My version of pylint is as follows:

$ pylint --version
pylint 2.4.2
astroid 2.3.1
Python 3.8.5 (default, Jan 27 2021, 15:41:15)
[GCC 9.3.0]

Is Apple clang version 12.0.5 available

Is Apple clang version 12.0.5 available ？

Create smoke tests to run as part of the build process

Windows version of the toolchain, easy to freeze when linking

I have supported the LLVM for Arm toolchain on the RT-Thread open source operating system, but I found a problem during use.

When I use it in a window environment, after the compilation is complete, there is a high probability of being stuck in the step of linking to generate elf. There is no such problem under WSL(ubuntu 20.04).

https://github.com/RT-Thread/rt-thread/tree/master/bsp/stm32/stm32l496-ali-developer

windows

WSL(ubuntu 20.04)

--print-libgcc-file-name points to a wrong location

clang  --config armv8m.main_hard_fp_nosys --target=armv8m.main-none-eabi -mfloat-abi=hard  -march=armv8m.main+fp --print-libgcc-file-name

/opt/install/LLVMEmbeddedToolchainForArm-13.0.0/lib/clang/13.0.0/lib/baremetal/libclang_rt.builtins-armv8m.main.a

but file does not exist.

Simple C++ program cannot seem to find stdint.h for Cortex-M85

Using LLVM 17 Preview, I am trying to compile a simple program:

#include <stdint.h>

int main(void)
{
    uint8_t count = 0;
    uint32_t result = 0;

    for (count = 0; count < 10; count++)
    {
        result += count;
    }

    return result;
}

with command:

clang -std=c++11 -x c++ -mfloat-abi=hard -O2 -mcpu=cortex-m85 --target=arm-none-eabi -mthumb -c -o test.o test.cpp

If I change the above command to mcpu=cortex-m33 or mcpu=cortex-m4 it works fine - no errors. But with the above command, I get the following output:

clang version 17.0.0
Target: arm-none-unknown-eabi
Thread model: posix
InstalledDir: /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin
 (in-process)
 "/opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/clang-17" -cc1 -triple thumbv8.1m.main-none-unknown-eabihf -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -nostdsysteminc -target-cpu cortex-m85 -target-feature -crc -target-feature -dotprod -target-feature +dsp -target-feature +mve -target-feature +mve.fp -target-feature +ras -target-feature -fp16fml -target-feature -bf16 -target-feature -sb -target-feature -i8mm -target-feature +lob -target-feature -cdecp0 -target-feature -cdecp1 -target-feature -cdecp2 -target-feature -cdecp3 -target-feature -cdecp4 -target-feature -cdecp5 -target-feature -cdecp6 -target-feature -cdecp7 -target-feature +pacbti -target-feature -hwdiv-arm -target-feature +hwdiv -target-feature +vfp2 -target-feature +vfp2sp -target-feature -vfp3 -target-feature +vfp3d16 -target-feature +vfp3d16sp -target-feature -vfp3sp -target-feature +fp16 -target-feature -vfp4 -target-feature +vfp4d16 -target-feature +vfp4d16sp -target-feature -vfp4sp -target-feature -fp-armv8 -target-feature +fp-armv8d16 -target-feature +fp-armv8d16sp -target-feature -fp-armv8sp -target-feature +fullfp16 -target-feature +fp64 -target-feature -d32 -target-feature -neon -target-feature -crypto -target-feature -sha2 -target-feature -aes -target-feature +strict-align -target-abi aapcs -mfloat-abi hard -Wunaligned-access -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/coder/workspace/peaks -resource-dir /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/lib/clang/17 -internal-isystem /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv8.1m.main_hard_fp/include/c++/v1 -internal-isystem /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv8m.main_hard_fp/include/c++/v1 -internal-isystem /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv7em_hard_fpv5_d16/include/c++/v1 -internal-isystem /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv7em_hard_fpv4_sp_d16/include/c++/v1 -internal-isystem /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/lib/clang/17/include -internal-isystem /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv8.1m.main_hard_fp/include -internal-isystem /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv8m.main_hard_fp/include -internal-isystem /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv7em_hard_fpv5_d16/include -internal-isystem /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv7em_hard_fpv4_sp_d16/include -O2 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir=/home/coder/workspace/peaks -ferror-limit 19 -fno-signed-char -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o test.o -x c++ test.cpp
clang -cc1 version 17.0.0 based upon LLVM 17.0.0-rc1 default target aarch64-linux-gnu
ignoring duplicate directory "/opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/lib/clang/17/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv8.1m.main_hard_fp/include/c++/v1
 /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv8m.main_hard_fp/include/c++/v1
 /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv7em_hard_fpv5_d16/include/c++/v1
 /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv7em_hard_fpv4_sp_d16/include/c++/v1
 /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/lib/clang/17/include
 /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv8.1m.main_hard_fp/include
 /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv8m.main_hard_fp/include
 /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv7em_hard_fpv5_d16/include
 /opt/LLVMEmbeddedToolchainForArm-17.0.0-Linux-x86_64/bin/../lib/clang-runtimes/arm-none-eabi/armv7em_hard_fpv4_sp_d16/include
End of search list.
test.cpp:5:5: error: unknown type name 'uint8_t'
    5 |     uint8_t count = 0;
      |     ^
test.cpp:6:5: error: unknown type name 'uint32_t'
    6 |     uint32_t result = 0;
      |     ^
2 errors generated.

'test' action has a few bugs

build.py all test does not run tests
build.py -v test fails with an exception
Lint checks are failing

Error when linking with some assembly files

I compiled this two assembly file

with the following parameters
'-std=c11 --config armv6m_soft_nofp_nosys.cfg -mno-unaligned-access -fshort-enums -fshort-wchar -g -ffunction-sections -fdata-sections -faapcs-bitfield-width -fno-common -Wall -Os'

But the linker report errors

with the following parameters
--config armv6m_soft_nofp_nosys.cfg -T /home/wsl/ls_sdk/soc/arm_cm/le501x/compiler/gnu/ble.ld -Wl,--gc-sections

Cannot select: intrinsic %llvm.arm.mve.vcvta

Using v16.0.0

#0 0x000055c5ce8e51da llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x22e51da)
 #1 0x000055c5ce8e2f64 llvm::sys::CleanupOnSignal(unsigned long) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x22e2f64)
 #2 0x000055c5ce844dd3 llvm::CrashRecoveryContext::HandleExit(int) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2244dd3)
 #3 0x000055c5ce8da06e llvm::sys::Process::Exit(int, bool) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x22da06e)
 #4 0x000055c5cd41dcb6 (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0xe1dcb6)
 #5 0x000055c5ce84c54f llvm::report_fatal_error(llvm::Twine const&, bool) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x224c54f)
 #6 0x000055c5cf8681a4 llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x32681a4)
 #7 0x000055c5cf86c012 llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x326c012)
 #8 0x000055c5cd7cd107 (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x11cd107)
 #9 0x000055c5cf8667bc llvm::SelectionDAGISel::DoInstructionSelection() (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x32667bc)
#10 0x000055c5cf86fce6 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x326fce6)
#11 0x000055c5cf8730ca llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x32730ca)
#12 0x000055c5cf874bea (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x3274bea)
#13 0x000055c5cd7d6124 (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x11d6124)
#14 0x000055c5cdd0e432 (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x170e432)
#15 0x000055c5ce21bf29 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x1c1bf29)
#16 0x000055c5ce21c1c1 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x1c1c1c1)
#17 0x000055c5ce21cc57 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x1c1cc57)
#18 0x000055c5cec67981 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2667981)
#19 0x000055c5cf9a66dd (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x33a66dd)
#20 0x000055c5d06bba09 clang::ParseAST(clang::Sema&, bool, bool) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x40bba09)
#21 0x000055c5cf9a71ed clang::CodeGenAction::ExecuteAction() (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x33a71ed)
#22 0x000055c5cf35f281 clang::FrontendAction::Execute() (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2d5f281)
#23 0x000055c5cf2f3f9a clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2cf3f9a)
#24 0x000055c5cf432ab3 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2e32ab3)
#25 0x000055c5cd41f6b4 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0xe1f6b4)
#26 0x000055c5cd41a5bf (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0xe1a5bf)
#27 0x000055c5cf1729a5 (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2b729a5)
#28 0x000055c5ce844cd5 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2244cd5)
#29 0x000055c5cf175178 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2b75178)
#30 0x000055c5cf1421ab clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2b421ab)
#31 0x000055c5cf142cf3 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2b42cf3)
#32 0x000055c5cf149bdf clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0x2b49bdf)
#33 0x000055c5cd41d491 clang_main(int, char**) (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0xe1d491)
#34 0x00007fc439c49083 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24083)
#35 0x000055c5cd41578a _start (/opt/LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/bin/clang-16+0xe1578a)
clang-16: error: clang frontend command failed with exit code 70 (use -v to see invocation)

SupportFunctions-ae2af8.zip

Remove -L from configuration files

After 73e1bdf, sysroot defaults to
DRIVER_PATH/lib/clang-runtimes/TARGET_TRIPLE. This is also the library
path used to find the 'rdimon' library.

Currently we specify this library path to make 'rdimon' searchable. But
since the sysroot change, it shouldn't be necessary anymore.

Provide binary releases for macOS

Could you please include llvm-link, llc and opt?

Could you please include the above files via "clang-tools-extra"? Our build system relies on those to do link time optimization.

Or are those steps completely outdated?

Release tar extracts all files into current folder instead of a new one

I went to https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm/releases/tag/release-15.0.2 and downloaded https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm/releases/download/release-15.0.2/LLVMEmbeddedToolchainForArm-15.0.2-Linux-AArch64.tar.gz.

Extracted it with:

tar -xvf <file>

And ended up with a bunch of new folders and files in the current dir, as opposed to one folder LLVMEmbeddedToolchainForArm-15.0.2-Linux-AArch64/.... The former is unexpected and a pain to clean up.

$ ls
CHANGELOG.md  LLVMEmbeddedToolchainForArm-15.0.2-Linux-AArch64.tar.gz  THIRD-PARTY-LICENSES.txt  bin   include  samples  third-party-licenses
LICENSE.txt   README.md                                                VERSION.txt               docs  lib      share

I could probably find a tar flag that prevents this but it's not a problem with other toolchain releases e.g. llvm's. Can we adjust the packaging to avoid this?

https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.6/clang+llvm-14.0.6-aarch64-linux-gnu.tar.xz if you need to look at one that does this correctly. Though I guess it's a matter of compressing a folder, rather than the contents of the folder.

Include profiling lib?

I'm trying to do profiling on the target with clang. Unfortunately the corresponding symbols __llvm_profile* are not included in clang_rt.

I have tried to include it via -DCOMPILER_RT_BUILD_PROFILE=ON in CMakeLists.txt:~600 but had no success. On the internet there is almost no information about how to build this part correctly.

Do you have any pointer or better could you please include it in the toolchain package?

Change directory organisation to reflect upstream LLVM default sysroot path

Upstream LLVM introduced a default sysroot path when targeting bare metal (link). It follows this pattern:

DRIVER_PATH/lib/clang-runtimes/TARGET_TRIPLE

Currently we install newlib and compiler-rt to DRIVER_PATH/targets/TARGET_TRIPLE, and this is used as sysroot.

The proposal here is to align our sysroot with upstream LLVM. Hence, we'd install newlib and compiler-rt to the new default path for bare metal compilations. Consequently, occurrences of --sysroot in configuration files can be removed as the default can be used.

Python 3.5 not supported by latest pip version

Pip 21.0 dropped supported for Python 3.5 (https://pip.pypa.io/en/stable/news/#id1). My Ubuntu Xenial's default Python3 is 3.5, so running setup.sh I get:

$ ./setup.sh
Collecting pip
  Using cached https://files.pythonhosted.org/packages/fe/ef/60d7ba03b5c442309ef42e7d69959f73aacccd0d86008362a681c4698e83/pip-21.0.1-py3-none-any.whl
Installing collected packages: pip
  Found existing installation: pip 8.1.1
    Uninstalling pip-8.1.1:
      Successfully uninstalled pip-8.1.1
Successfully installed pip-21.0.1
Traceback (most recent call last):
  File "/tmp/LLVM-embedded-toolchain-for-Arm/venv/bin/pip", line 7, in <module>
    from pip._internal.cli.main import main
  File "/tmp/LLVM-embedded-toolchain-for-Arm/venv/lib/python3.5/site-packages/pip/_internal/cli/main.py", line 60
    sys.stderr.write(f"ERROR: {exc}")
                                   ^

Since this formatting syntax is a 3.6 and above feature. (https://docs.python.org/3/reference/lexical_analysis.html#f-strings)

I can change the script to use the previous pip version and that works:

$ git diff
diff --git a/setup.sh b/setup.sh
index ffda148..c2cee8e 100755
--- a/setup.sh
+++ b/setup.sh
@@ -21,7 +21,7 @@ python3 -m venv venv

 . venv/bin/activate

-pip install --upgrade pip
+pip install --upgrade "pip<=20.3.4"
 pip install --upgrade wheel
 pip install --upgrade setuptools
 pip install pyyaml

However you also get:

DEPRECATION: Python 3.5 reached the end of its life on September 13th, 2020. Please upgrade your Python as Python 3.5 is no longer maintained. pip 21.0 will drop support for Python 3.5 in January 2021. pip 21.0 will remove support for this functionality.

I would consider bumping the required version to 3.6. It means Ubuntu Xenial users would have to install a newer python3 but that can be done with https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa quite easily.

In the meantime I can make a PR with the above fix anyway if that's useful.

Builtin math symbols are missing on llvm 15.0.2(libm.a)

Seems a lot of symbols are missing in libm.a:

ld.lld -m armelf --entry=__start -nostdlib --gc-sections --cref -Map=nuttx.map -Tboards/arm/stm32/viewtool-stm32f107/scripts/flash.ld.tmp  -L staging -L arch/arm/src/board  \
	-o nuttx   \
	--start-group -lsched -ldrivers -lboards -lc -lmm -larch -lapps -lnet -lfs -lbinfmt -lboard prebuilts/clang/linux/arm/bin/../lib/clang-runtimes/armv7m_soft_nofp/lib/libclang_rt.builtins-armv7m.a prebuilts/clang/linux/arm/bin/../lib/clang-runtimes/armv7m_soft_nofp/lib/libm.a --end-group
ld.lld: error: undefined symbol: __fpclassifyd
>>> referenced by lib_dtoa_engine.c
>>>               lib_dtoa_engine.o:(__dtoa_engine) in archive staging/libc.a
>>> referenced by lib_dtoa_engine.c
>>>               lib_dtoa_engine.o:(__dtoa_engine) in archive staging/libc.a
make[1]: *** [Makefile:174: nuttx] Error 1
make[1]: Leaving directory 'arch/arm/src'

LLVM v14.0.0:

$ find -name libm.a | xargs ls -l
-rw-rw-r-- 1 archer archer 635510 11月 16 21:37 ./lib/clang-runtimes/aarch64_/lib/libm.a
-rw-rw-r-- 1 archer archer 585986 11月 16 21:37 ./lib/clang-runtimes/armv6m_soft_nofp/lib/libm.a
-rw-rw-r-- 1 archer archer 589378 11月 16 21:37 ./lib/clang-runtimes/armv7em_hard_fpv4_sp_d16/lib/libm.a
-rw-rw-r-- 1 archer archer 537300 11月 16 21:37 ./lib/clang-runtimes/armv7em_hard_fpv5_d16/lib/libm.a
-rw-rw-r-- 1 archer archer 582502 11月 16 21:37 ./lib/clang-runtimes/armv7em_soft_nofp/lib/libm.a
-rw-rw-r-- 1 archer archer 582490 11月 16 21:37 ./lib/clang-runtimes/armv7m_soft_nofp/lib/libm.a
-rw-rw-r-- 1 archer archer 581482 11月 16 21:37 ./lib/clang-runtimes/armv8.1m.main_hard_fp/lib/libm.a
-rw-rw-r-- 1 archer archer 610646 11月 16 21:37 ./lib/clang-runtimes/armv8.1m.main_hard_nofp_mve/lib/libm.a
-rw-rw-r-- 1 archer archer 577998 11月 16 21:37 ./lib/clang-runtimes/armv8.1m.main_soft_nofp_nomve/lib/libm.a
-rw-rw-r-- 1 archer archer 524952 11月 16 21:37 ./lib/clang-runtimes/armv8m.main_hard_fp/lib/libm.a
-rw-rw-r-- 1 archer archer 578022 11月 16 21:37 ./lib/clang-runtimes/armv8m.main_soft_nofp/lib/libm.a

LLVM v15.0.2, (The file size of libm.a is significantly smaller than version 14.0.0)

$ find -name libm.a | xargs ls -l
-rw-r--r-- 1 archer archer 912 11月 22 13:42 ./lib/clang-runtimes/aarch64/lib/libm.a
-rw-r--r-- 1 archer archer 800 11月 22 13:42 ./lib/clang-runtimes/armv6m_soft_nofp/lib/libm.a
-rw-r--r-- 1 archer archer 808 11月 22 13:42 ./lib/clang-runtimes/armv7em_hard_fpv4_sp_d16/lib/libm.a
-rw-r--r-- 1 archer archer 804 11月 22 13:42 ./lib/clang-runtimes/armv7em_hard_fpv5_d16/lib/libm.a
-rw-r--r-- 1 archer archer 800 11月 22 13:42 ./lib/clang-runtimes/armv7em_soft_nofp/lib/libm.a
-rw-r--r-- 1 archer archer 800 11月 22 13:42 ./lib/clang-runtimes/armv7m_soft_nofp/lib/libm.a
-rw-r--r-- 1 archer archer 796 11月 22 13:42 ./lib/clang-runtimes/armv8.1m.main_hard_fp/lib/libm.a
-rw-r--r-- 1 archer archer 792 11月 22 13:42 ./lib/clang-runtimes/armv8.1m.main_hard_nofp_mve/lib/libm.a
-rw-r--r-- 1 archer archer 788 11月 22 13:42 ./lib/clang-runtimes/armv8.1m.main_soft_nofp_nomve/lib/libm.a
-rw-r--r-- 1 archer archer 792 11月 22 13:42 ./lib/clang-runtimes/armv8m.main_hard_fp/lib/libm.a
-rw-r--r-- 1 archer archer 788 11月 22 13:42 ./lib/clang-runtimes/armv8m.main_soft_nofp/lib/libm.a

Incorrectly formatted link in README.md

One of the links in README.md does not render correctly due to incorrect markdown. This one:

[releases|https://github.com/llvm/llvm-project/releases]

gentoo linux: error: unable to create target: 'No available targets are compatible with triple "x86_64-unknown-linux-gnu"'

In Gentoo, the gcc is x86_64-pc-linux-gnu-gcc:

x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.2.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.2.1/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.2.1_p20211127 p0' --disable-esp --enable-libstdcxx-time --with-build-config=bootstrap-lto --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --enable-lto --without-isl --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.1 20211127 (Gentoo 11.2.1_p20211127 p0)

 $ cat a.c
#include <stdio.h>
int main(void)
{
    return 0;
}
$ clang a.c
clang: /usr/lib64/libtinfo.so.5: no version information available (required by clang)
/home/yongxiang/work/llvm-for-arm/bin/clang-13: /usr/lib64/libtinfo.so.5: no version information available (required by /home/yongxiang/work/llvm-for-arm/bin/clang-13)
error: unable to create target: 'No available targets are compatible with triple "x86_64-unknown-linux-gnu"'
1 error generated.

Is armv7em + FPv5-SP-D16-M supported?

Hei everyone,

I am trying to use the toolchain to build a specific configuration for FPU: -mfpu=fpv5-sp-d16. More exactly, I am trying to have single-precision.

According to documentation here, both single and double precision are included in v7E-M + FPv5-DP-D16-M.
Is this correct?

In the repo, I noticed that there is only one .cfg file for fpv5, omitting DP or SP (armv7em_hard_fpv5_d16.cfg).
Moreover, the runtime libs only support this version ./lib/clang-runtimes/armv7em_hard_fpv5_d16.

My questions would be:
Can armv7em_hard_fpv5_d16 libraries be used for both single and double precision? Can I use, for example, /lib/clang-runtimes/armv7em_hard_fpv5_d16/lib/libclang_rt.builtins-armv7em.a from this repo for -mfpu=fpv5-sp-d16?

Thank you! :)

Distribution via vcpkg requires zip/tarball archives

We distribute tools via Microsoft's vcpgk (see https://artifacts.keil.arm.com/vcpkg-ce-registry/). In case of llvm embedded toolchain we refer directly to the release archives hosted on GitHub.

Unfortunately, with the release 17.0.1 this doesn't work for the Mac distribution anymore. vcpkg does not support .dmg archives but only .zip or .tar. Would it be possible to provide a .tar.xz in addition to the .dmg for Mac?

Building from source / elaboration

Hello,

I had an issue running the prebuild linux toolchain on RedHat7 because of glibc and other libraries mismatch, so had to build it from the source.

Running the build command mentioned in building-from-source.md

cmake .. -GNinja -DFETCHCONTENT_QUIET=OFF
did not succeed as is, because build system is picking an outdated default host compiler, so it is required to add an explicit path to a valid one.

-DCMAKE_C_COMPILER=/path/tovalidcompiler
-DCMAKE_CXX_COMPILER=/path/tovalidcompiler

It seems that it's also necessary to set LLVMEmbeddedToolchainForArm_COMMIT to avoid following issue with git command

CMake Error at llvm16/LLVM-embedded-toolchain-for-Arm-release-16.0.0/cmake/generate_version_txt.cmake:1 (execute_process):
  execute_process failed command indexes:
 
    1: "Child return code: 128"

Can you please kindly elaborate a little more on the different options to ensure a smooth build from source process ?
Thanks in advance

Is it possible to generate ram assess codes by static base register(r9) instead of PC relative for position independency?

I'm implementing a XIP elfloader for CortexM series, the .text/.ro will be in flash and .bss/.data will be in sram.

There are 2 options for position independency:

embedded position independency by -fropi -frwpi
But I found some .bss/.data access code will use PC-relative form, which will cause hardfault. Because .text is in flash and .bss/.data is in ram, so the offset calculated on virtual address is not fit.
GOT-based position independency by -fPIC
But it seems -mno-pic-data-is-text-relative is not supported by armv7m-eabi.

Is there any other options available for this purpose?

BTW: Is it a BUG if PC-relative form for accessing variable is generated with -frwpi defined?

The llvm clang version I'm using is 16.0.0.

picolibc instead of newlib

Very excited to see this happening! My first question is have you evaluated picolibc instead of newlib? Differences between newlib(-nano) are discussed in picolibc/picolibc#103.

Support kasan for arm-none-unknown-eabi'

clang-16: error: unsupported option '-fsanitize=kernel-address' for target 'arm-none-unknown-eabi', gcc is support arm-none-unknown-eabi

about command line length limit in windows

Command Line:
G:\project\vsf\example\template\project\cmake\aic8800\build>E:\Software\armllvm\bin\clang.exe -mcpu=cortex-m4 -mthumb --config armv6m_soft_nofp_rdimon -Ofast -std=gnu11 -Wall -fno-builtin -fno-strict-aliasing -fdata-sections -fms-extensions -ffunction-sections -fms-extensions -fdiagnostics-color=always -Xlinker -TG:/project/vsf/example/template/project/cmake/aic8800/linker.ld -Xlinker -Map=output.map -mabi=aapcs -march=armv7e-m @CMakeFiles\vsf_template.rsp -o vsf_template.elf -Wl,--out-implib,libvsf_template.dll.a -Wl,--major-image-version,0,--minor-image-version,0
clang: error: unable to execute command: Couldn't execute program 'E:/Software/armllvm/bin/ld.lld.exe': 文件名或扩展名太长。 (0xCE)
clang: error: ld.lld command failed with exit code 1 (use -v to see invocation)

the compiler version is 14.0.0.
It seems that the problem is because of the command line length limit in win10, is it possible to fix this?
There are 700 .c files in the project, so it will make the link command too long in windows.

arm-software / llvm-embedded-toolchain-for-arm Goto Github PK