From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25849 invoked by alias); 30 Nov 2012 14:13:38 -0000 Received: (qmail 25827 invoked by uid 22791); 30 Nov 2012 14:13:36 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-bk0-f47.google.com (HELO mail-bk0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Nov 2012 14:13:21 +0000 Received: by mail-bk0-f47.google.com with SMTP id j4so233992bkw.20 for ; Fri, 30 Nov 2012 06:13:20 -0800 (PST) Received: by 10.204.154.202 with SMTP id p10mr405925bkw.29.1354284800266; Fri, 30 Nov 2012 06:13:20 -0800 (PST) Received: from [192.168.2.2] ([46.218.123.34]) by mx.google.com with ESMTPS id z5sm3520988bkv.11.2012.11.30.06.13.17 (version=SSLv3 cipher=OTHER); Fri, 30 Nov 2012 06:13:18 -0800 (PST) Message-ID: <1354284795.6211.28.camel@mathieu-UX21E> Subject: using -fsplit-stack From: mathieu lacage To: gcc-help@gcc.gnu.org Date: Fri, 30 Nov 2012 14:13:00 -0000 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg00223.txt.bz2 hi, I would like to use -fsplit-stack in a small application of mine so I tried a simple test program to see if it can be used to build binaries that can have an unlimited stack space (since the stack is supposed to be allocated on the heap on demand, I naively expect it to be limited by the heap allocator) and run and be debugged on a normal linux installation. $ cat > test.c << EOF #include int main(int argc, char *argv[]) { char buffer[10000000]; printf("hello %p\n", &buffer); return 0; } EOF $ gcc -fsplit-stack ./test.c -o test $ ./test hello 0x7fbecfd58960 Segmentation fault (core dumped) Obviously, the same test will also segfault without -fsplit-stack but now, it segfaults with an interesting backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7de3af5 in do_lookup_x (new_hash=2090266759, old_hash=0x7ffff6e7b110, result=0x7ffff6e7b0e0, scope=0x7ffff7ffe5a0, i=0, flags=1, skip=0x0, undef_map=0x7ffff7ffa9a8) at dl-lookup.c:82 82 dl-lookup.c: No such file or directory. (gdb) bt #0 0x00007ffff7de3af5 in do_lookup_x (new_hash=2090266759, old_hash=0x7ffff6e7b110, result=0x7ffff6e7b0e0, scope=0x7ffff7ffe5a0, i=0, flags=1, skip=0x0, undef_map=0x7ffff7ffa9a8) at dl-lookup.c:82 #1 0x00007ffff7de4533 in _dl_lookup_symbol_x (undef_name=0x7ffff7816f25 "free", undef_map=0x7ffff7ffa9a8, ref=0x7ffff6e7b170, symbol_scope=0x7ffff7ffad00, version=0x7ffff7fd9180, type_class=1, flags=1, skip_map=0x0) at dl-lookup.c:739 #2 0x00007ffff7de8784 in _dl_fixup (l=, reloc_arg=) at ../elf/dl-runtime.c:119 '#3 0x00007ffff7def245 in _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:42 #4 0x00007ffff784dac4 in _IO_vfprintf_internal (s=, format=, ap=) at vfprintf.c:2052 #5 0x00007ffff78588d9 in __printf (format=) at printf.c:35 #6 0x0000000000400d21 in main () It looks like printf cannot find free anymore. Strange. Because I can imagine the myriad of ways in which this could fail and lead to this kind of strange hard-to-debug problem, here are a couple of questions about stack-split itself: 1) I have disassembled the generated code and I see one symbol that appears to be related to this:__morestack Is there documentation somewhere on the exact semantics that is supposed to be provided by this function ? Are there other functions that the stack-split code will potentially call ? 2) What is the story about interaction with code that is not compiled with stack-split code ? i.e., can I call non-stack-split code from stack-split code and vice-versa ? I read the gcc documentation: When code compiled with `-fsplit-stack' calls code compiled without `-fsplit-stack', there may not be much stack space available for the latter code to run. If compiling all code, including library code, with `-fsplit-stack' is not an option, then the linker can fix up these calls so that the code compiled without `-fsplit-stack' always has a large stack. Support for this is implemented in the gold linker in GNU binutils release 2.21 and later. I think that this means that the gold linker will check that every library that a binary links to was compiled with split-stack and if not change the generated code to do something differen. I think that it also means that GNU linker does not do this and that I need to link my binary myself with gold. I tried to do this actually but I have not yet been able to find the right combination of options to make gold find the binaries that contain __morestack, printf, and __stack_check_fail (yeah, I am using a dumb ubuntu box) gold -lc ./test.o -o test gold: error: ./test.o: could not convert call to '__morestack' to '__morestack_non_split' ./test.o:test.c:function main: error: undefined reference to '__morestack' But, anyway, I can't see how that link-time code change would work for libraries. Say, binary A links to B and C. A and B are stack-split. C is not. What is the linker going to do ?. What happens at runtime ? Does the loader perform a similar check ? (if so, which loader/version ? 3) gdb: Does gcc generate the right kind of dwarf information for gdb to understand how to unwind a stack-split stack ? 4) Any data on CPU/memory performance for using -fsplit-stack ? i.e., what would be the downsides of compiling everything with this feature on ? Well, anyway, at this point, I welcome feedback/ideas of any kind :) thanks for this pretty cool feature, Mathieu