When setjmp/longjmp/exceptions are used on Windows it's necessary to store+restore additional information from the TEB.
I didn't find any official documentation about the values to be saved, but found the corresponding boost/context implemenataion:
abf8e04e23
This is similar to the special TIB handling on x86/x86_64 on Windows.
Without this fix an exception in a fiber segfaults without any output:
ruby -e "Fiber.new{ raise 'test' }.resume"
These apparently break compilation on old MacOS toolchains, because the
MachO section name is capped to 16 chars (although, on my MacOS, at
least, the section name just gets truncated). Nevertheless, these serve
no purpose on non-ELF platforms (they're part of the LSB Linux ABI).
[Bug #20677]
This wasn't looking at the right macro name for pac-ret support, so if
Ruby was compiled with pac-ret but NOT BTI, then the ELF note would not
be emitted.
We do not implement CET shadow-stack switching in amd64 Context.S. If
you compile Ruby with `-fcf-protection=full` and run it with
`GLIBC_TUNABLES=glibc.cpu.hwcaps=SHSTK` exported, it will crash with a
control flow exception.
Configure the appropriate notes at the end of Context.S
[Bug #18061]
This partially reverts https://github.com/ruby/ruby/pull/10944; now that
we decided to pass CFLAGS to $(CC) when assembling .S files, we don't
need these autoconf macros that capture the state of
__ARM_FEATURE{PAC|BTI}_DEFAULT.
[Bug #20601]
When running on newer Intel processors supporting the feature,
OpenBSD enforces indirect branch tracking. Without this endbr64
instruction, jumps to the coroutine_transfer function result
in SIGILL on OpenBSD/amd64 when using such processors.
The OpenBSD Ruby ports have been using a patch similar to this
for the past two months.
From some research, cet.h has been supported by GCC for about
6 years and LLVM for about 4 years.
This changes the automatic detection of -fstack-protector,
-D_FORTIFY_SOURCE, and -mbranch-protection to write to $hardenflags
instead of $XCFLAGS. The definition of $cflags is changed to
"$hardenflags $orig_cflags $optflags $debugflags $warnflags" to match.
Furthermore, these flags are _prepended_ to $hardenflags, rather than
appended.
The implications of doing this are as follows:
* If a CRuby builder specifies cflags="-mbranch-protection=foobar" at
the ./configure script, and the configure script detects that
-mbranch-protection=pac-ret is accepted, then GCC will be invoked as
"gcc -mbranch-protection=pac-ret -mbranch-protection=foobar". Since
the last flags take precedence, that means that user-supplied values
of these flags in $cflags will take priority.
* Likewise, if a CRuby builder explicitly specifies
"hardenflags=-mbranch-protection=foobar", because we _prepend_ to
$hardenflags in our autoconf script, we will still invoke GCC as
"gcc -mbranch-protection=pac-ret -mbranch-protection=foobar".
* If a CRuby builder specifies CFLAGS="..." at the configure line,
automatic detection of hardening flags is ignored as before.
* C extensions will _also_ be built with hardening flags now as well
(this was not the case by default before because the detected flags
went into $XCFLAGS).
Additionally, as part of this work, I changed how the detection of
PAC/BTI in Context.S works. Rather than appending the autodetected
option to ASFLAGS, we simply compile a set of test programs with the
actual CFLAGS in use to determine what PAC/BTI settings were actually
chosen by the builder. Context.S is made aware of these choices through
some custom macros.
The result of this work is that:
* Ruby will continue to choose some sensible defaults for hardening
options for the C compiler
* Distributors are able to specify CFLAGS that are consistent with their
distribution and override these defaults
* Context.S will react to whatever -mbranch-protection is actually in
use, not what was autodetected
* Extensions get built with hardening flags too.
[Bug #20154]
[Bug #20520]
With `--std=c99` option coroutine/arm64/Context.h errs:
```
In file included from cont.c:26:
coroutine/arm64/Context.h:59:5: error: call to undeclared function 'asm'; ISO C99 and later do not support
implicit function declarations [-Wimplicit-function-declaration]
59 | asm ("hint #8;" : "+r"(r17) : "r"(r16));
| ^
```
Also move the common function header.
In WebAssembly C ABI, the linear stack pointer must be always aligned
to 16 bytes like other archs.
The misaligned stack pointer causes some weird memory corruption since
compiler assumes the aligned stack pointer.
We don't need to save/restore x30 twice, and we can just use `ret`,
which uses x30 as return address register instead of explicit `ret <reg>`
instruction. This also allows us to use `autiasp` instead of `autia1716`
and we can skip setting SP/LR to x16/x17.
Also the size of register save area is shrunk by 16 bytes due to the
removal of extra x30 save/restore.
No encodings are guaranteed in C compilers, and other than UTF-8
encodings may be assumed in some platforms, e.g., CP932 on Windows
Japanese edition, and may result in compilation errors.
* add coroutines for ppc & ppc64
* fix universal coroutine to include ppc & ppc64
* add powerpc*-darwin to configure.ac
* fix thread_pthread for older systems
OpenBSD is the only platform that uses this support by default,
and it did not work because while OpenBSD supports alloca, it does
not include alloca.h.
This should be backported to Ruby 2.7.
From George Koehler
