ARM-software / LLVM-embedded-toolchain-for-Arm

A project dedicated to building LLVM toolchain for Arm and AArch64 embedded targets.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

anchao opened this issue · comments

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

Could be. The test coverage is very light at present. Got a small reproducer?

Please check the attachment and rename it from test.log to test.c ( test.log )

Compile:

$ clang -c -Wstrict-prototypes -Oz -fno-strict-aliasing -fomit-frame-pointer -mthumb -fno-builtin -fshort-enums -fno-common -Wall -Wshadow -Wundef -ffunction-sections -fdata-sections -march=armv7-m --config armv7m_soft_nofp -mtune=cortex-m3 -mfloat-abi=soft -mfloat-abi=soft  test.c -o test.o

Link fail caused by __fpclassifyd not found(should be implement in libm.a):

$ ld.lld -m armelf --entry=__start -nostdlib --gc-sections   -o nuttx test.o  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
ld.lld: error: undefined symbol: __fpclassifyd
>>> referenced by test.c
>>>               test.o:(__dtoa_engine)
>>> referenced by test.c
>>>               test.o:(__dtoa_engine)

__fpclassifyd is defined in libc.a. Quite why that is I'm not sure, but we build picolibc in a fairly typical way so I suspect it's a deliberate decision on the part of the picolibc project.

Thanks for reply, i think this might be a bug ... not all projects will use the builtin libc implementation, In the previous v14.0.0, these symbols can be found out in libm.a, I have no idea why libm.a in v15.0.2 with no contents.

Between 14 and 15 we switched from newlib to picolibc which is a big change.

Is it possible to separate two parts of picolib to generate libc and libm separately?

Merging libc & libm was a deliberate decision so I think the answer is no, sorry.

Thanks so much for your reply, but this is really a bad experience. If use picolib's libc directly, the generated result will be confusing. See the generated map below, malloc() is wrongly linked to picolib, but in fact we have private memory allocator to override stdlib:

 800513c  800513c        0     1                 $t.2
 800513d  800513d       4c     1                 __malloc_grow_chunk
 8005184  8005184        0     1                 $d.3
 8005188  8005188       cc     4         /home/archer/code/k03/k1/prebuilts/clang/linux/arm/bin/../lib/clang-runtimes/armv7m_soft_nofp/lib/libc.a(nano-malloc-malloc.c.o):(.text.malloc)
 8005188  8005188        0     1                 $t.4
 8005189  8005189       cc     1                 malloc
 8005189  8005189       cc     1                 __malloc_malloc
 8005248  8005248        0     1                 $d.5
 8005254  8005254       3c     4         /home/archer/code/k03/k1/prebuilts/clang/linux/arm/bin/../lib/clang-runtimes/armv7m_soft_nofp/lib/libc.a(libc_picolib_picosbrk.c.o):(.text.sbrk)

I know this behavior depends on the implementation of picolib, but I still want to let ARM to know that maybe most developers will faced similar issue ...

Thanks for letting us know. @voltur01 FYI. I suspect there are ways to achieve what you want with picolibc but the picolibc project itself may be a better place to ask.

@keith-packard agree that it's better to achieve all math functions into both libc and libm to improve the usability and compatibility:
picolibc/picolibc#142