This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SafeStack proposal in GCC
- From: Michael Matz <matz at suse dot de>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Rich Felker <dalias at libc dot org>, nd at arm dot com, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 10 May 2016 14:51:25 +0200 (CEST)
- Subject: Re: SafeStack proposal in GCC
- Authentication-results: sourceware.org; auth=none
- References: <CAFA9rWPkb=eV0GhvFeOnd4pRVh=N3fSifYBwZjy9Ndh68BmBww at mail dot gmail dot com> <0d50f0ef01b24c25a79a6f18eaddfd6d at REXA dot intranet dot epfl dot ch> <CANL6WeqEwFYx2H-sv81K8CDFypiJ+ray+xPyRH+7kitTpD8bqw at mail dot gmail dot com> <20160507054212 dot GE21636 at brightrain dot aerifal dot cx> <alpine dot LSU dot 2 dot 20 dot 1605092101000 dot 13156 at wotan dot suse dot de> <20160509193503 dot GF21636 at brightrain dot aerifal dot cx> <alpine dot LSU dot 2 dot 20 dot 1605092147020 dot 13156 at wotan dot suse dot de> <20160509204352 dot GG21636 at brightrain dot aerifal dot cx> <alpine dot LSU dot 2 dot 20 dot 1605092321460 dot 13156 at wotan dot suse dot de> <5731B4D2 dot 2030003 at arm dot com>
Hi,
On Tue, 10 May 2016, Szabolcs Nagy wrote:
> setjmp is defined so that the compiler can treat it
> specially and the caller has to make sure certain
> objects are volatile, cannot appear in arbitrary
> places (e.g. in the declaration of a vla), longjmp
> must be in same thread etc.
>
> all those requirements that make setjmp implementible
> at all were missing from the getcontext specs, so you
> can call it through a function pointer and access
> non-volatile modified local state after the second
> return, etc. (the compiler treating "getcontext"
> specially is a hack, not justified by any standard.)
Because _it was removed from the standards_, which is the point of this
sub-thread. If it had stayed it would have gotten the same caveats that
setjmp/longjmp got over time to "make it implementable" ...
> i think both gccgo and qemu can setcontext into another
> thread, so when getcontext returns all tls object
> addresses are wrong.. the semantics of this case was
> not properly defined anywhere (and there are
> implementation internal objects with thread local
> storage duration like fenv so this matters even if
> the caller does not use tls). this is unlikely to
> work correctly with whatever safestack implementation.
... like saying something about this ...
> if setcontext finishes executing the last linked
> context in the main thread it was not clearly
> specified what cleanups will be performed.
... or this, or any of the other use-cases. And don't claim that
setjmp/longjmp were completely specified always. E.g. the interaction
with threads (naturally) was only put in when threads were put in. The
mentioning of the abstract machine state was only there when that concept
was added, and so on.
> there is just a never ending list of issues with
> these apis, so unless there is an actual proposal
> how to tighten their specification, any caller of
> the context apis rely on undefined semantics.
TBH, that's probably fighting against wind mills. Architectures who care
about co-routines implementable in a working way will have a sensible
*context implementation, others won't. Too bad for them.
Ciao,
Michael.