Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Wed, 9 Apr 2014 09:05:46 +0200, Svante Signell <svante.signell@gmail.com> wrote:
> On Fri, 2014-04-04 at 21:14 +0200, Samuel Thibault wrote:
> > Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a Ãcrit :
> > > On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor <iant@google.com> wrote:
> > > > Go can work without split stack.  In that case libgo will use much
> > > > larger stacks for goroutines, to reduce the chance of running out of
> > > > stack space (see StackMin in libgo/runtime/proc.c).  So the number of
> > > > simultaneous goroutines that can be run will be limited.  This is
> > > > usually OK on x86_64 but it does hamper Go programs running on 32-bit
> > > > x86.
> > > 
> > > OK, but that's not the most pressing issue we're having right now.
> > > Anyway, as it stands, the split-stack code doesn't work on Hurd, so I
> > > disabled it in r200434 as follows:
> > 
> > Maybe you'd want to re-enable it, now that we have got rid of threadvars :)
> 
> I don't think it is a good idea. I've patched gcc-4.9-20140406 to make
> gccgo build and tested with -fsplit-stack enabled (with and without the
> gold linker). Without split stack around 70 libgo tests pass and 50
> fails. With it enabled all tests fail. [...]

> LD_PRELOAD=../gcc-4.9-4.9-20140406/build/i486-gnu/libgo/.libs/libgo.so.5.0.0 ./a.out
> mmap errno 1073741846
> fatal error: mmap

Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
and similar configury is correct for the Hurd, and figure out what's
going on with the zero-page unmapping (discussed earlier in this thread),
and then mmap failing with 1073741846 (EINVAL).


> Patches for gccgo on GNU/Hurd will be submitted to the Debian BTS.

Just a suggestion, but in my opinion, it'd make more sense to first get
such patches integrated upstream.  (Same also for the GCC Ada patches.)
GCC Go support (as well as Ada) clearly is not a critical thing to first
get into Debian GNU/Hurd, and the total maintenance/integration overhead
would be lower if these patches would just percolate into Debian GCC from
upstream.


GrÃÃe,
 Thomas

Attachment: pgpWax898nw4E.pgp
Description: PGP signature