[Top][All Lists]

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

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

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


On Sat, 22 Jun 2013 01:15:08 +0200, Richard Braun <rbraun@sceen.net> wrote:
> 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 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?  ;-)
> Unless I'm mistaken, vm_allocate (along with vm_map and vm_deallocate)
> is never used through a real system call but always as an RPC from the
> Hurd. To make sure that's the case, see if rpctrace catches the call.

Heh, I was so sure it was a system call, so it didn't even occur to me to
simply check this...  Simple enough:

    task48(pid17605)->vm_map (0 0 0 1  (null) 0 1 1 7 1) = 0x4 ((os/kern) 
invalid argument) 
    task48(pid17605)->vm_protect (0 0 0 0) = 0 
    task48(pid17605)->vm_deallocate (0 4096) = 0 
    task48(pid17605)->vm_allocate (0 4096 1) = 0 0

(By the way, the zero-size vm_map is the one we discussed at
So, the split-stack runtime unmaps the zero page -- and then is happily
re-using it for the following page-sized allocation.  So, vm_acllocate
doesn't behave erratically after all.


Attachment: pgpzg9lJETlI1.pgp
Description: PGP signature

reply via email to

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