[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) |
Hi!
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
<http://news.gmane.org/find-root.php?message_id=%3C87sj8522zx.fsf%40kepler.schwinge.homeip.net%3E>.)
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.
Grüße,
Thomas
pgpzg9lJETlI1.pgp
Description: PGP signature