-
Notifications
You must be signed in to change notification settings - Fork 6.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CONFIG_THREAD_LOCAL_STORAGE (selected by PICOLIBC) sends sparse into an infinite loop #63417
Comments
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time. |
This is a bug in the |
Reproduced again with most recent sparse commit adceff0ab6e3, "Reported" at https://marc.info/?l=linux-sparse&m=170366399601223&w=2 (from https://sparse.docs.kernel.org/) The infinite loop is located in
I git bisected the infinite loop to this sparse commit from @lucvoo
Interestingly, The trigger is in the very short @keith-packard is there a way to disable --- a/cgcc
+++ b/cgcc
@@ -106,6 +106,8 @@ if ($do_check) {
chomp($multiarch_dir); # possibly remove '\n' from compiler
$check .= " -multiarch-dir " . $multiarch_dir if $multiarch_dir;
+ $check = "valgrind $check";
+
print "$check\n" if $verbose;
if ($do_compile) {
system ($check) == 0 or exit 1; |
Picolibc (as built in the SDK) uses thread local storage internally for a few variables, including 'errno'. If you don't use any of those variables, you can disable TLS. I'm not sure that's entirely satisfactory here though; presumably you want to use sparse with lots of different configurations. If you build picolibc as a module, then you can disable thread local storage. The only limitation here is that you cannot use the C++ standard library as that uses the C library ABI, including TLS variables exposed by libc like errno. |
https://docs.zephyrproject.org/latest/develop/languages/c/picolibc.html Thank you! I'm typically not using zephyr/west.yml and of course it didn't have the picolibc module :-( I switched back to After a few other, time-consuming detours to #67035 and #67036, the following workaround runs fine and avoids this infinite loop! I'll edit the description at the top and add it.
I'm trying to keep the workaround(s) for this issue as small and as least intrusive as possible for two reasons:
|
Actually, isn't that size inconsistency a serious problem in the Zephyr build system? A sparse-specific issue for sure but a Zephyr problem nevertheless. Re-opening! |
Easy reproduction with the attached
|
Thanks. |
sparse fix confirmed! Thanks @lucvoo. @keith-packard now the same command fails differently:
EDIT: this is older #63003 Interestingly,
I will open new bugs if needed, this one has become too long. |
The infinite loop is triggered by some fairly simple code on Zephyr and is caused by some exchange of pseudos done without checking the canonical order. Fix this by adding the check for the canonical order. Also use can_move_to() instead of the simpler one_use() to check the dominance of the moved pseudos. Link: zephyrproject-rtos/zephyr#63417 Link: https://lore.kernel.org/linux-sparse/AD16C022-C5F3-4DA2-A1A0-775E4C95A7A1@intel.com/ Reported-by: Marc Herbert <marc.herbert@intel.com> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
The infinite loop is triggered by some fairly simple code on Zephyr and is caused by some exchange of pseudos done without checking the canonical order. Fix this by adding the check for the canonical order. Also use can_move_to() instead of the simpler one_use() to check the dominance of the moved pseudos. Link: zephyrproject-rtos/zephyr#63417 Link: https://lore.kernel.org/linux-sparse/AD16C022-C5F3-4DA2-A1A0-775E4C95A7A1@intel.com/ Reported-by: Marc Herbert <marc.herbert@intel.com> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
I just got bit by that again... |
My bad:
Of course this is not visible when buried under 400 lines of sparse warnings.... So maybe what's needed is some sort of |
I haven't any idea how to do this; presumably some Kconfig magic? |
Describe the bug
This is admittedly a bug in the
sparse
tool itself but it's triggered by very specific Zephyr conditions.EDIT: the infinite loop has been confirmed and fixed in sparse. Other Zephyr issues mentioned below remain, tracked in other bugs if needed.
To Reproduce
Steps to reproduce the behavior:
Same infinite loop with intel_ish_5_4_1, arduino_due and others. No infinite loop with
intel_adsp_cavs25
(which does not haveTHREAD_LOCAL_STORAGE
)Workaround 1
EDIT: a bit more complicated now, see below.
Disabling
tls.c
still avoids the issue but it requires using the separate picolibc module as added tozephyr/west.yml
by d0c75f3. Then the following command avoids the infinite loop:Workaround 2
CONFIG_MINIMAL_LIBC=y seems to also turn off THREAD_LOCAL_STORAGE
Expected behavior
No infinite loop.
Impact
Impossible to use
sparse
static analyzer on these platforms.Harder to debug other
sparse
issues like #63003Logs and console output
See above
Environment (please complete the following information):
Linux
Zephyr SDK 0.16.1
Zephyr commit ea4a463
marc-hb/sparse@3848a76ba49f
Additional context
The text was updated successfully, but these errors were encountered: