<abu[7]>
I tried, but there is nothing to lint actually. 'de' does not define a function, but is redefined to output llvm code
<tankf33der>
somewhere must be a key
<abu[7]>
I think the generated base.ll is correct
<abu[7]>
Right!
<tankf33der>
disable non-related code to run co, only core and co
<abu[7]>
I run only (co 'a (yield 1)), so no non-related code should interfer I think
<tankf33der>
without pil ? only bin/picolisp
<tankf33der>
?
<abu[7]>
I can see that 'a' is started, yields back to 'T', then 'a' again and 'run' returns
<abu[7]>
Nothing else executes
<tankf33der>
ok
<abu[7]>
But even if we did so, we don't know the reason
<tankf33der>
do you debug on termux or debian ?
<abu[7]>
Both, but never saw the problem on Termux
<abu[7]>
(ie. Arm64)
<tankf33der>
try debug on debian, you could compile with different llvm versions
<abu[7]>
This would not help, I *have* a case where it fails. If it does not fail, we cannot find the problem
<tankf33der>
what if you must save related before jump and restore it on return?
<abu[7]>
I cannot I think
<abu[7]>
Dst: is not changed by the code
<abu[7]>
It changes automagically
<tankf33der>
ok
<abu[7]>
If I do something with it, it does not change
<abu[7]>
but perhaps some other var
<abu[7]>
Really a Mystery!
<tankf33der>
what is your llvm version on arm?
<abu[7]>
I don't ever know whether 'Dst:' is in a register (which is perhaps not properly saved across setjmp/longjmp), or on the stack (perhaps overwritten by buggy code), or both
<abu[7]>
18
<abu[7]>
s/ever/even
<abu[7]>
But if the stack were overwritten, the value in Dst: would be more random
<abu[7]>
But it has a valid (though wrong) pointer
<abu[7]>
And the program would crash at *this* place
<abu[7]>
(more on the stack overwritten)
<abu[7]>
It crashes later, when the value of Dst: is actually used
<tankf33der>
What if all long-setjmps are used incorrectly and the code breaking is a coincidence, and you do not step on a landmine?
<abu[7]>
Can you explain a little more?
<abu[7]>
If used incorrectly it would not be a coincidence
<tankf33der>
what functions are use long-setjmps? they could crash too
<tankf33der>
i can try to test
<tankf33der>
i have 30mins
<abu[7]>
In Pil 'catch', 'err', 'co', 'yield' and 'main' call setjmp iirc
<tankf33der>
ok
<abu[7]>
Longjmp is in 'err', 'throm' and 'co'/'yield'
<abu[7]>
throw*
<abu[7]>
Perhaps more places
<abu[7]>
They all work correctly it seems, just a var gets changed ;)
<abu[7]>
Strange is that we did not notice before
<abu[7]>
The changes last week were minimal, and reverting some of them did not help
<abu[7]>
Reverting *all* probably helps, but then again we don't know what it was
<abu[7]>
and we were back to bugs
<tankf33der>
do not revert, push forward
<abu[7]>
Yes, better
<abu[7]>
I should dump all registers before and after 'run' and see if any of those reserved for register vars by the x86 ABI has changed
<abu[7]>
Even if a register changed illegally, what to do then? Bug report? How to explain it to the LLVM devs?
<abu[7]>
"Please debug my Pil code" :D
<tankf33der>
:)
<abu[7]>
Can you see a pattern if it depends on the x86 libc version?
<abu[7]>
set/longjmp glue code is in libc
<tankf33der>
debian and freebsd are different, no pattern
<abu[7]>
good
<tankf33der>
and alpine vs. debian are different
<abu[7]>
ok
<tankf33der>
catch-throw no errors
<abu[7]>
Perhaps ask in #llvm on irc.oftc.net? Or some
<abu[7]>
catch and throw do not use any vars before or after the jump
<tankf33der>
i do not believe they help
<abu[7]>
co is very involved compared to them
<abu[7]>
Yeah, probably
<tankf33der>
nikic@php.net
<abu[7]>
481 users on #llvm
<tankf33der>
Nikita Popov
<tankf33der>
try better this email with short question