[llvm-dev] ARM baremetal linking

[Goran Mekić via llvm-dev]

On Mon, Oct 08, 2018 at 05:47:11PM +0100, Peter Smith wrote:
> 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

Strange:

clang60 -target arm-none-eabi -march=armv7-m -mcpu=cortex-m4 -print-resource-dir
/usr/local/llvm60/lib/clang/6.0.1

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

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

I made a mistake when I said it's not breaking on entrypoint. I just
didn't enable debug build, so the lldb output was different. For
completenes, this is the linker command now:

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

This is what debugger says when -g is added to CFLAGS:

lldb nuttx
(lldb) target create "nuttx"
Current executable set to 'nuttx' (arm).
(lldb) gdb-remote 3333                                                                                                                                                                                                            Process 1 stopped
* thread #1, stop reason = signal SIGTRAP
    frame #0: 0x08000188 nuttx`__start at stm32_start.c:274
   271 	 ****************************************************************************/
   272
   273 	void __start(void)
-> 274 	{
   275 	  const uint32_t *src;
   276 	  uint32_t *dest;
   277
(lldb) register read
General Purpose Registers:
        r0 = 0x00000000
        r1 = 0x00000000
        r2 = 0x00000000
        r3 = 0x00000000
        r4 = 0x00000000
        r5 = 0x00000000
        r6 = 0x00000000
        r7 = 0x00000000
        r8 = 0x00000000
        r9 = 0x00000000
       r10 = 0x00000000
       r11 = 0x00000000
       r12 = 0x00000000
        sp = 0x200016c8
        lr = 0xffffffff
        pc = 0x08000188  nuttx`__start at stm32_start.c:274
      cpsr = 0x00000000

(lldb)

In other words, it does break on entrypoint.

> 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.
I compiled without hardware FPU now. I also added
-DCMAKE_BUILD_TYPE=Debug

GCC build readelf (without debug): https://pastebin.com/vJwCkD09
Clang build readelf (with debug): https://pastebin.com/t75WQQvG

When I diff'ed those two, what I noticed is this:

-  Tag_ARM_ISA_use: Yes
+  Tag_ARM_ISA_use: No

Of course, there's tons of differences there, but this one is a bit funky.

Regards,
meka

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181008/61ad0a41/attachment.sig>