This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
- From: Samuel Thibault <samuel dot thibault at gnu dot org>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: svante dot signell at gmail dot com, Ian Lance Taylor <iant at google dot com>, gcc-patches at gcc dot gnu dot org, bug-hurd at gnu dot org, fotis dot koutoulakis at gmail dot com, Roland McGrath <roland at hack dot frob dot com>
- Date: Fri, 11 Apr 2014 23:51:44 +0200
- Subject: Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
- Authentication-results: sourceware.org; auth=none
- References: <8761x7nkks dot fsf at kepler dot schwinge dot homeip dot net> <20130621231655 dot 24D002C14C at topped-with-meat dot com> <87r4fumx2g dot fsf at kepler dot schwinge dot homeip dot net> <CAKOQZ8wZOf8MBdVKiyDcggFBs3A48+QckAoB7XJm+b+E3rkAxQ at mail dot gmail dot com> <87ip10o90k dot fsf at kepler dot schwinge dot homeip dot net> <20140404191416 dot GG5350 at type> <1397027146 dot 1276 dot 29 dot camel at G3620 dot my dot own dot domain> <87fvln6jjp dot fsf at schwinge dot name>
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
i386.
> 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 ../sysdeps/mach/hurd/mmap.c:145
#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. */
void
__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 ());
}
Yes...
So, do we really want to let munmap poke a hole at address 0 and thus
let further vm_map() return address 0?
Samuel