[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: Samuel Thibault
Subject: Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
Date: Fri, 11 Apr 2014 23:51:44 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> and similar configury is correct for the Hurd,

It's not.  I've checked what TARGET_THREAD_SPLIT_STACK_OFFSET is, it's
an offset inside the tcbhead_t structure, and we don't have that field
at all...  We may want to extend our tcbhead_t the same way as Linux

> and figure out what's
> going on with the zero-page unmapping (discussed earlier in this thread),
> and then mmap failing with 1073741846 (EINVAL).

Here is the backtrace

#0  __vm_map (target_task=1, address=address@entry=0x1029cc4, 
size=size@entry=0, mask=mask@entry=0, anywhere=1, 
memory_object=memory_object@entry=0, offset=offset@entry=0, 
    copy=copy@entry=1, cur_protection=cur_protection@entry=1, 
max_protection=max_protection@entry=7, inheritance=inheritance@entry=1)
    at /usr/src/eglibc-2.18/build-tree/hurd-i386-libc/mach/vm_map.c:56
#1  0x0118a3e8 in __mmap (addr=0x0, len=0, prot=4, flags=2, fd=-1, offset=0) at 
#2  0x0804960d in __morestack_load_mmap ()
#3  0x08049d12 in __libc_csu_init ()
#4  0x010b4671 in __libc_start_main (main=0x80489dd <main>, argc=1, 
argv=0x1029de4, init=0x8049cc0 <__libc_csu_init>, fini=0x8049d30 
<__libc_csu_fini>, rtld_fini=0xfb90 <_dl_fini>, 
    stack_end=0x1029ddc) at libc-start.c:246
#5  0x08048901 in _start ()

It's indeed:

/* This function is called at program startup time to make sure that
   mmap, munmap, and getpagesize are resolved if linking dynamically.
   We want to resolve them while we have enough stack for them, rather
   than calling into the dynamic linker while low on stack space.  */

__morestack_load_mmap (void)
  /* Call with bogus values to run faster.  We don't care if the call
     fails.  Pass __MORESTACK_CURRENT_SEGMENT to make sure that any
     TLS accessor function is resolved.  */
  mmap (__morestack_current_segment, 0, PROT_READ, MAP_ANONYMOUS, -1, 0);
  mprotect (NULL, 0, 0);
  munmap (0, getpagesize ());


So, do we really want to let munmap poke a hole at address 0 and thus
let further vm_map() return address 0?


reply via email to

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