xt-clang: support bundled newlib #59291
Conversation
|
Compliance check failure is due to multi-line #if where the second line starts with spaces. |
dcpleung
requested review from
nashif,
nordic-krch,
andyross and
tejlmand
as code owners
zephyrbot
added
area: Toolchains
zephyrbot
requested review from
cfriedt,
jeremybettis,
keith-packard,
nordicjm and
stephanosio
|
The newlib in xt-clang is too broken to support Zephyr. So closing it for now... |
include/zephyr/posix/sys/stat.h
Outdated
| * there are no corresponding *_DECLARED macros, so we need to define | ||
| * them manually to avoid them being re-declared. | ||
| */ | ||
| #define HAS__TIMESPEC_H 0 |
There was a problem hiding this comment.
Vague concerns about a name in the 'application' namespace, but prefixing it with '_' would risk conflicting with a C library define.
| @@ -23,6 +23,8 @@ | |||
| #include <zephyr/sys/mem_manage.h> | |||
| #include <sys/time.h> | |||
|
|
|||
| #include <newlib.h> | |||
There was a problem hiding this comment.
Surely one of the above headers already includes this? Odd, if not. But, nbd in any case.
| @@ -303,10 +305,8 @@ void *_sbrk(intptr_t count) | |||
| } | |||
| __weak FUNC_ALIAS(_sbrk, sbrk, void *); | |||
|
|
|||
| #ifdef CONFIG_MULTITHREADING | |||
There was a problem hiding this comment.
Uh, this isn't good -- what does this old version of newlib do for locking? Seems like this will cause all kinds of trouble if multiple threads call into stdio or anything else in newlib that requires locking.
There was a problem hiding this comment.
From what I have read, old newlib is not really thread safe. That's why they introduced the retargetable locks.
| @@ -450,7 +450,21 @@ void __retarget_lock_release_recursive(_LOCK_T lock) | |||
| __ASSERT_NO_MSG(lock != NULL); | |||
| k_mutex_unlock((struct k_mutex *)lock); | |||
| } | |||
| #endif /* CONFIG_MULTITHREADING */ | |||
| #else /* CONFIG_MULTITHREADING && _RETARGETABLE_LOCKING */ | |||
There was a problem hiding this comment.
Do you want to look into sharing the common malloc implementation instead of using the newlib one? I realize it's not directly aligned with your goals here, but I don't know anyone else poking at newlib code...
There was a problem hiding this comment.
I cannot find a definite way to exclude a function from a static library during linking. IIRC, providing multiple implementation may result in the linker either complaining, or picking one depending on linking order. If it is latter, cmake scripts may need to be changed to ensure ordering all the time.
|
From what I can tell, the newlib in xt-clang is very old and that there are various issues... After given it some thoughs, I think we should not re-introduce the old behavior here. Given that we have picolibc, we should be using that instead, IMHO. |
|
Yeah, iirc, you had some adventures with that too. Good luck! |
Add a board config file for intel_ace15_mtpm which is simply a copy from intel_adsp_cavs25. Signed-off-by: Daniel Leung <[email protected]>
|
Need to re-open this... this is needed to use the profiling tools provided by Cadence. |
Xtensa xt-clang has very old newlib (possibly 2.0.0) which does not have sys/_timespec.h, and also various typedefs done. So we need to avoid including non-existing header file, and avoid re-declaring the typedefs. Signed-off-by: Daniel Leung <[email protected]>
...for old newlib version. This is needed to use the newlib bundled with Xtensa xt-clang toolchain, which predates the introduction of retargetable locking. Signed-off-by: Daniel Leung <[email protected]>
The newlib bundled with Xtensa xt-clang is an old version which predates the introduction of retargatable locking. So we need to skip all the locking tests but retains the stress tests if xt-clang is used. Signed-off-by: Daniel Leung <[email protected]>
Typecast the arguments to both toupper() and tolower() to int. Some ancient newlib has a way to generate warning with -Wall so we need to be strict about the type of argument. Signed-off-by: Daniel Leung <[email protected]>
xt-clang and its ancient newlib define uintptr_t as unsigned int instead of unsigned long which results in compiler complaining about any logging using %lx for uintptr_t of different type. So use the toolchain provided PRIxPTR and PRIuPTR for proper formatting. Signed-off-by: Daniel Leung <[email protected]>
Clang would generate floating pointer instructions to process floats as there usually is no soft float support from host or vendor LLVM toolchain. Without CONFIG_FPU enabled, the platform runs assuming no floating point instructions would be used, and encountering such instructions would result in exception. So skip this test if CONFIG_FPU is not enabled to avoid such exceptions. Signed-off-by: Daniel Leung <[email protected]>
Clang would generate floating pointer instructions to process floats as there usually is no soft float support from host or vendor LLVM toolchain. Without CONFIG_FPU enabled, the platform runs assuming no floating point instructions would be used, and encountering such instructions would result in exception. So only print float if CONFIG_FPU is enabled to avoid such exceptions. Signed-off-by: Daniel Leung <[email protected]>
This introduces CONFIG_NEWLIB_LIBC_IN_TOOLCHAIN_IS_ANCIENT to indicate if the newlib coming from the toolchain is of very old verion (usually predates the retargetable locks). There are various changes needed to support ancient newlib with regard to function prototypes, data types and header files. Signed-off-by: Daniel Leung <[email protected]>
This sets the variable TOOLCHAIN_HAS_NEWLIB to true for xt-clang so we can use the built-in newlib provided by the Xtensa toolchain. Note that C++ STL support with newlib is broken (same as xcc), so exclude xt-clang from the libcxx tests for now. Signed-off-by: Daniel Leung <[email protected]>
This PR contains commits to support the (very old) newlib bundled with Xtensa LLVM toolchain (xt-clang). See individual commits for details.