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: Rich Felker <dalias at libc dot org>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 9 May 2016 22:03:02 +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>
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
> > > The *context APIs are deprecated and I'm not sure they're worth
> > > supporting with this. It would be a good excuse to get people to
> > > stop using them.
> >
> > How? POSIX decided to remove the facilities without any adequate
> > replacement (thread aren't).
>
> Threads work just as well as the ucontext api for coroutines. Due to the
> requirement to save/restore signal masks, the latter requires a syscall,
> making it no faster than a voluntary context switch via futex syscall.
Uhm, no. If you disregard efficiency, sure, POSIX threads are sometimes a
replacement on some platforms. They still have completely different
activation models (being synchronous with *context, for which you need
even further slow synchronization in a threading model).
> Most of the other hacks people used the ucontext API for were complete
> hacks with undefined behavior, anyway.
Sure, that doesn't imply the facility should be removed. I can misuse all
kinds of stuff.
> BTW it's not even possible to implement makecontext on most targets due
> to the wacky variadic calling convention it uses -- in most ABIs,
> there's simply no way to shift the variadic args into the right slots
> for calling the start function for the new context without knowing their
> types, and the implementation has no way to know the types. So it's
> really an unusably broken API.
Of course. But _that_ implies that a workable replacement should have
been put in place, not the unrealistic stance POSIX took with the removal:
makecontext2(ucontext_t *ucp, void (*func)(void*), void* cookie);
Done. I never understood why they left in the hugely
unuseful {sig,}{set,long}jmp() but removed the actually useful *context()
(amended somehow like above).
Ciao,
Michael.