Split-stack is fundamentally incompatible with __hurd_threadvar_location et
al (and cthreads). We won't ever be able to use split-stack until we
change to a proper thread-pointer-based implementation
(i.e. segment-register based stuff for i386).
On Sat, Jun 22, 2013 at 12:52:03AM +0200, Thomas Schwinge wrote:
> But anyway, what is the split-stack run-time/startup code doing so that
> it makes vm_allocate behave erratically? Isn't vm_allocate a real system
> call after all, but relies on some threadvar state? It's now too late to
> figure
Hi!
This is tracked down from the GCC Go testsuite, where every execution
test would fail à la:
mmap errno 1073741846
fatal error: mmap
That is EINVAL (but that actually is a straw man, as it should turn out),
and mmap has been invoked from [GCC]/libbacktrace/mmap.c:backtrace_alloc
(but
