<https://github.com/rust-lang/rust/issues/126984> has been resolved.
Remove the workaround that was introduced to suppress it.
This reverts commit 254edbcad4cfd6a8af32e3297c1037d7984c3c49.
* Use a no-asm feature instead of an asm feature
This works better as core/alloc/std have trouble supporting default
featues in this crate.
Signed-off-by: Joe Richey <joerichey@google.com>
* Have no-asm disable arm assembly intrinsics
Signed-off-by: Joe Richey <joerichey@google.com>
1. In UEFI x86 arch, probestack need triple underscore.
2. In UEFI, probestack function do things like _chkstk(in MSVC).
MSVC x32's _chkstk and cygwin/mingw's _alloca adjust %esp themselves
MSVC x64's __chkstk and cygwin/mingw's ___chkstk_ms do not adjust
%rsp themselves.
But current probestack doesn't adjust esp. And LLVM doesn't generate
sub %eax, %esp after probestack. So we adjust esp in probestack like
MSVC x32's _chkstk.
This turns the following backtrace,
```
>> bt
#0 0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```
To this:
```
>>> bt
#0 0x0000555555574e47 in __rust_probestack ()
#1 0x00005555555595ba in test::main ()
#2 0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
#3 0x0000555555561ae3 in std::panicking::try::do_call ()
#4 0x000055555556595a in __rust_maybe_catch_panic ()
#5 0x000055555555af9b in std::rt::lang_start_internal ()
#6 0x00005555555594d5 in std::rt::lang_start ()
#7 0x000055555555977b in main ()
```
Use the "volatile" option and the "memory" clobber on inline asm that does
things like return directly, to reduce the chances of compilers rearranging
the code.
It looks like the old `__rust_probestack` routine is incompatible with newer
linux kernels. My best guess for this is that the kernel's auto-growth logic is
failing to trigger, causing what looks like a legitimate segfault to get
delivered. My best guess for why *that's* happening is that the faulting address
is below `%rsp`, whereas previously all faulting stack addresses were above
`%rsp`. The probestack routine does not modify `%rsp` as it's probing the stack,
and presumably newer kernels are interpreting this as a legitimate violation.
This commit tweaks the probestack routine to instead update `%rsp` incrementally
as probing happens. The ABI of the function, however, requires that `%rsp`
isn't changed as part of the function so it's restored at the end to the
previous value.
