[llvm-dev] ARM baremetal linking

[Peter Smith via llvm-dev]

On Mon, 8 Oct 2018 at 17:13, Goran Mekić <meka at tilda.center> wrote:
>
> On Mon, Oct 08, 2018 at 10:23:07AM +0100, Peter Smith wrote:
> > For building compiler-rt standalone for Arm there is the docs page
> > https://llvm.org/docs/HowToCrossCompileBuiltinsOnArm.html . That will
> > be a good place to start. The hardest part is usually fighting your
> > way past the CMAKE try compile step. I strongly recommend using a
> > version of cmake >= 3.6 so that you can use the
> > -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY .
> >
> > Hope that this gets you a little bit further.
> >
> > Peter
>
> I chose to go with this option, and these are the steps
>
> Remove arm_Thumb1_VFPv2_SOURCES from arm_Thumb1_SOURCES because
> Cortext-M4 is Armv7E-M according to https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M4
>
> cmake ../compiler-rt \
>   -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY \
>   -DCOMPILER_RT_OS_DIR="baremetal" \
>   -DCOMPILER_RT_BUILD_BUILTINS=ON \
>   -DCOMPILER_RT_BUILD_SANITIZERS=OFF \
>   -DCOMPILER_RT_BUILD_XRAY=OFF \
>   -DCOMPILER_RT_BUILD_LIBFUZZER=OFF \
>   -DCOMPILER_RT_BUILD_PROFILE=OFF \
>   -DCMAKE_C_COMPILER=/usr/local/libexec/ccache/clang60 \
>   -DCMAKE_C_COMPILER_TARGET="arm-none-eabi" \
>   -DCMAKE_AR=/usr/local/bin/llvm-ar60 \
>   -DCMAKE_NM=/usr/local/bin/llvm-nm60 \
>   -DCMAKE_RANLIB=/usr/local/bin/llvm-ranlib60 \
>   -DCOMPILER_RT_BAREMETAL_BUILD=ON \
>   -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON \
>   -DLLVM_CONFIG_PATH=/usr/local/bin/llvm-config60 \
>   -DCMAKE_C_FLAGS="-target arm-none-eabi -march=armv7e-m -mcpu=cortex-m4 -isystem /usr/local/include -isystem /usr/include" \
>   -DCMAKE_ASM_FLAGS="-target arm-none-eabi -march=armv7e-m -mcpu=cortex-m4" \
>   -DCOMPILER_RT_INCLUDE_TESTS=OFF
>
> After "make && sudo make install" I now have
> /usr/local/lib/baremetal/libclang_rt.builtins-arm.a. I'm wondering why
> that location, and not what clang60 returns for libgcc which is
>
> clang60 -target arm-none-eabi -march=armv7-m -mcpu=cortex-m4 -print-libgcc-file-name
> /usr/local/llvm60/lib/clang/6.0.1/lib/libclang_rt.builtins-arm.a
>

By default I think that Clang looks for compiler-rt in the resource
directory, this is usually relative to the clang executable, something
like ../lib/clang/6.0.0/lib/baremetal/libclang_rt.builtins-armv7m.a
for a --target=armv7-m-none-eabi. You can find out where this is with
--print-resource-dir

> Anyway, I linked manually using:
>
> ld.lld60 -m armelf --entry=__start -T/usr/home/meka/repos/nuttx/nuttx/configs/nucleo-f4x1re/scripts/f401re.ld -L"/usr/home/meka/repos/nuttx/nuttx/staging" -L"/usr/home/meka/repos/nuttx/nuttx/arch/arm/src/board" -o "/usr/home/meka/repos/nuttx/nuttx/nuttx" --start-group -lsched -ldrivers -lconfigs -lc -lmm -larch -lxx -lapps -lfs -lbinfmt -lxx -lboard /usr/local/lib/baremetal/libclang_rt.builtins-arm.a --end-group
>
> It seams to almost work as I don't get an error imediatly on entrypoint,
> which is good (but not much beyond entrypoint either):
>
> lldb nuttx
> (lldb) target create "nuttx"
> Current executable set to 'nuttx' (arm).
> (lldb) gdb-remote 3333
> Process 1 stopped
> * thread #1, stop reason = signal SIGINT
>     frame #0: 0x08000188 nuttx`__start
> nuttx`__start:
> ->  0x8000188 <+0>:  push   {r7, lr}
>     0x800018a <+2>:  bl     0x800bb30                 ; stm32_clockconfig
>     0x800018e <+6>:  bl     0x8003bd0                 ; stm32_lowsetup
>     0x8000192 <+10>: bl     0x80009f8                 ; stm32_gpioinit
> (lldb)
>
If there is a SIGINT on push {r7, lr} that might indicate that the
stack pointer register isn't set correctly. Depending on how your
libraries work you may have to do this yourself prior to entering
__start. Will be worth seeing what SP (R13) is in your debugger at
that point.

> On the WikiPedia link I read that M4 doesn't have FPU, only M4F has it,
> so I was wondering if that's the cause of this error. Even if it isn't
> the cause of error, how would I build compiler-rt for this chip and
> explicitely state that it doesn't have FPU? Also, I obviously need to
> build with debug symbols (which I forgot this time), but that should
> be easy. Any other tip on how to make more progress is welcome!
>

Adding -mfpu=none -mfloat-abi=soft to the CMAKE_C_FLAGS and
CMAKE_ASM_FLAGS should prevent any use of floating point. There is a
check in the CMake files to remove the VFP sources if a particular
macro isn't defined with the compilation flags so this should make it
unnecessary to manual edit the CMakeLists.txt file.

Peter

> Regards,
> meka