[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schwinge
Subject: GCC's -fsplit-stack disturbing Mach's vm_allocate
Date: Sat, 22 Jun 2013 00:52:03 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)


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 that also doesn't matter, as it should turn out), and it's the
simple case where mmap just calls vm_allocate to get private anonymous
memory (just one single page in this case).

What happens is that vm_allocate (which I understand to be a real system
call?!) is returning KERN_SUCCESS but at the same time doesn't set the
address it reserved.  At first, I reproducted this behavior with GDB
(»call __vm_allocate(1,0x21ff930,4096,1)«; observe that for the first
call, the value at 0x21ff930 doesn't change) in one of the executables
the GCC Go testsuite left behind, and after having realized that these
are all built with -fsplit-stack, it is reproducable as follows:

    #include <mach.h>
    #include <stdio.h>
    int main(void)
      int err;
      vm_address_t addr = 0;
      int i;
      for (i = 0; i < 3; ++i)
          err = vm_allocate(mach_task_self(), &addr, 4096, 1);
          printf("%u %p\n", err, (void *) addr);
      return 0;

    $ gcc -Wall v.c -fsplit-stack 
    $ ./a.out 
    0 (nil)
    0 0x102c000
    0 0x102e000

GCC's -fsplit-stack is documented at
and/or <http://nickclifton.livejournal.com/6889.html>.  Due to our
current threavar machinery in glibc, we can't expect it to work,
But contrary to what I thought, it actually *is* enabled for us, too, so
aside from the threadvar issue, the run-time code accesses %gs:0x30
([GCC]/libgcc/config/i386/morestack.S), which is not appropriate either.
I'm now testing a GCC build with split-stack disabled.

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 it out today, and I have enough other things on my plate anyway.
But surely Richard and/or Samuel will have some comments on this?  ;-)


Attachment: pgpZmSzPigJbh.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]