This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SafeStack proposal in GCC


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]