Nothing uses the return value.  This will make the next changes
easier.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

We must change the atomic read on panic entry to `Acquire`, to pick up
a possible an `always_panic` on another thread.

We add `count` to the names of panic_count::get and ::is_zaero,
because now there is another reason why panic ought to maybe abort.
Renaming these ensures that we have checked every call site to ensure
that they don't need further adjustment.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>

As per
  rust-lang#81858 (comment)

Suggested-by: Mara Bos <m-ou.se@m-ou.se>
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Unwinding after fork() in the child is UB on some platforms, because
on those (including musl) malloc can be UB in the child of a
multithreaded program, and unwinding must box for the payload.

Even if it's safe, unwinding past fork() in the child causes whatever
traps the unwind to return twice.  This is very strange and clearly
not desirable.  With the default behaviour of the thread library, this
can even result in a panic in the child being transformed into zero
exit status (ie, success) as seen in the parent!

Fixes rust-lang#79740.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>

This is safe (does not involve heap allocation) but we don't yet have
a test to ensure that stays true.  That will come in a moment.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>

This tests that we can indeed safely panic after fork, both
a raw libc::fork and in a Command pre_exec hook.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>

Previoously, if somehow this program got a wrong argument, it would
panic in the re-executed child.  But that looks like a "success"
for this program!  We mustn't panic unless everything is great.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Our existing tests are only on Unix.  We want a general one too.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

This test failed on an earlier version of this branch, where this did
not work properly, so I know the test works.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

fork fails there.  The failure message is confusing: so c.status()
returns an Err, the closure panics, and the test thinks the panic was
propagated from inside the child.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>

Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort!

See eg
  rust-lang#81858 (comment)

This is probably a bug, but (i) we want to avoid that bug rather than
trying to fix it now and (ii) it would better to use a signal that is
less at risk of strangeness.

I grepped the rust-lang/rut codebase for SIGUSR and there were no hits.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort!

See eg
  rust-lang#81858 (comment)

This is probably a bug, but we don't want to entangle this MR with it.
When it's fixed, this commit should be reverted.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

And link to the issue.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>