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): ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Clas - Pastebin.com
Clang build readelf (with debug): ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Clas - Pastebin.com
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