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.
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]
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]
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.
It is more conventional to use compiler to pre-process and
assemble the `.S` file rather than forcing Makefile to use `.s`.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65952 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
