IMHO this is superseded by https://reviews.freebsd.org/D40188

IMHO this is superseded by https://reviews.freebsd.org/D40188

In D40407#920099, @imp wrote:

So why does this fix things? Otherwise, looks like it's OK

proper patch: https://reviews.freebsd.org/D40415

Now that I am thinking about it, this may not be a compiler issue - the C standard specifies that the value of non-volatile local variables modified between the setjmp call and the longjmp is unspecified. So making these static is actually the right way to go.

This patch actually works around the problem:

Add missing TSEXIT

and indeed, further testing reveals that the issue does not get fixed by this change (nor by moving setstackmark), only hidden; any changes to smark contents are *not* visible after the jump, which in practice means we are most likely leaking memory, or worse

@jilles I looked into this more and it seems that this is actually a miscompilation, possibly caused by the LLVM optimizer getting confused because of the long jumps.

whoops, missed it due to phabric email doesn't show it,
constify struct xregs_banks, thank you

<@q66> bapt: anyway, to reproduce: i added this to memalloc.c https://gist.github.com/q66/978ca271db9ea32c8641209eb90f2f85
<@q66> then all you have to do is exec the sh binary, and press ctrl-c
<@q66> in plain prompt
<@q66> https://gist.github.com/q66/99295f340eeaffae740d53e0cc603ad0
<@q66> actually, printf("POPSTACKMARK %p %p\n", mark->stackp, stackp); is more explanatory
<@q66> you will see a POPSTACKMARK 0 0 upon ctrl-c
<@q66> e.g. like https://gist.github.com/q66/61b70ecabb510bbdf86a11e330f89893
<@q66> if i compile without the zeroing
<@q66> i will get a bogus address
<@q66> in mark->stackp

Since the docs people have said OK, I'll commit this once D39970 is ready... and you certify that this adds nothing to the igor or mandoc -T lint output.

In D39970#910936, @jo_bruelltuete.com wrote:

style?

the issue was caught by the author of chimera linux when compiling it with lto and clang16

To me, it looks like that situation can't actually happen. If there is an error or SIGINT during early initialization, state will still be 0 and the if (setjmp(main_handler.loc)) block will immediately call exitshell(exitstatus) without touching smark. If I'm wrong, please provide a reproduction scenario.

So why does this fix things? Otherwise, looks like it's OK