This is the mail archive of the
mailing list for the GCC project.
Re: SafeStack proposal in GCC
- From: Ian Lance Taylor <iant at google dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Michael Matz <matz at suse dot de>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 9 May 2016 12:42:54 -0700
- 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>
On Mon, May 9, 2016 at 12:35 PM, Rich Felker <email@example.com> wrote:
> On Mon, May 09, 2016 at 09:02:33PM +0200, Michael Matz wrote:
>> On Sat, 7 May 2016, Rich Felker wrote:
>> > > > * sigaltstack and swapcontext are broken too.
>> > >
>> > > We have prototype that supports swapcontext that we're happy to
>> > > release, but it clearly requires more work before being ready to merge
>> > > upstream.
>> > 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.
No, threads do not work as well. You can not ignore efficiency
considerations. Coroutine switching is much faster with setcontext,
even though it does a system call.
> Most of the other hacks people used the ucontext API for were complete
> hacks with undefined behavior, anyway.
And yet code like gccgo's library works, on many different systems.
> 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.
I certainly agree that makecontext is broken by design. But it is
easy enough, and safe, to use makecontext with functions that take no
arguments. I would fully support an effort to propagate a replacement
for makecontext that can actually work more generally. I think the
current approach of simply dropping support is unwise.