rust/src/libstd/sys
kennytm 8b8c6ee796
Rollup merge of #47912 - cuviper:glibc-stack-guard, r=alexcrichton
Use a range to identify SIGSEGV in stack guards

Previously, the `guard::init()` and `guard::current()` functions were
returning a `usize` address representing the top of the stack guard,
respectively for the main thread and for spawned threads.  The `SIGSEGV`
handler on `unix` targets checked if a fault was within one page below that
address, if so reporting it as a stack overflow.

Now `unix` targets report a `Range<usize>` representing the guard memory,
so it can cover arbitrary guard sizes.  Non-`unix` targets which always
return `None` for guards now do so with `Option<!>`, so they don't pay any
overhead.

For `linux-gnu` in particular, the previous guard upper-bound was
`stackaddr + guardsize`, as the protected memory was *inside* the stack.
This was a glibc bug, and starting from 2.27 they are moving the guard
*past* the end of the stack.  However, there's no simple way for us to know
where the guard page actually lies, so now we declare it as the whole range
of `stackaddr ± guardsize`, and any fault therein will be called a stack
overflow.  This fixes #47863.
2018-02-04 23:28:57 +08:00
..
cloudabi Use a range to identify SIGSEGV in stack guards 2018-01-31 11:41:29 -08:00
redox Use a range to identify SIGSEGV in stack guards 2018-01-31 11:41:29 -08:00
unix Use a range to identify SIGSEGV in stack guards 2018-01-31 11:41:29 -08:00
wasm Rollup merge of #47912 - cuviper:glibc-stack-guard, r=alexcrichton 2018-02-04 23:28:57 +08:00
windows Use a range to identify SIGSEGV in stack guards 2018-01-31 11:41:29 -08:00
mod.rs Make the documentation build work on CloudABI. 2018-01-11 11:29:52 +01:00