From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12857 invoked by alias); 30 Nov 2012 15:16:38 -0000 Received: (qmail 12823 invoked by uid 22791); 30 Nov 2012 15:16:33 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Nov 2012 15:16:22 +0000 Received: by mail-ie0-f175.google.com with SMTP id qd14so782040ieb.20 for ; Fri, 30 Nov 2012 07:16:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DxK2cO6xwmAIrseQ0Xku9nulxs5V9QG+PwBoxgEV7vs=; b=NPzxmP41l6f1oCT1qmPEyjKL3DXZqnksjram5eYluJGucC+/0ExW3nlW1G01ZJZwf9 1gHy++RZzOmIpNIyZm3nPbkZrhLUd7AjEOOqLPDrP+kHIyBzJALSiTU13uQC9D+y2tdP iBHUHuaO0UiiscF28zaj/Vq822Tgtb+hh7FcIf827AmNiZouhzDmDuyJ3/3rcm17kIOh MO8Kt7SRRgq0lM3DCynZqO/wrNn0dqU8+14yi8J2fogMiV5GbDW72ooWKkzlAP3Euvc/ gycA+keUJSSRI2GagjCmHkB3JeXk+ZKqm9haJhOllal/JZPZopnb4v9KGwRq8t7KcSJ4 cHSg== MIME-Version: 1.0 Received: by 10.42.74.73 with SMTP id v9mr1134432icj.37.1354288581662; Fri, 30 Nov 2012 07:16:21 -0800 (PST) Received: by 10.64.15.195 with HTTP; Fri, 30 Nov 2012 07:16:21 -0800 (PST) In-Reply-To: <1354284795.6211.28.camel@mathieu-UX21E> References: <1354284795.6211.28.camel@mathieu-UX21E> Date: Fri, 30 Nov 2012 15:16:00 -0000 Message-ID: Subject: Re: using -fsplit-stack From: Ian Lance Taylor To: mathieu lacage Cc: gcc-help@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmw2zGwSoqxrSZ5edqAn1cOv4qiphm94adpm2BL8nTHOxvMU9XGzmvVkkLMz266v/9hFTx0uVxRJxFT928eAKjxrJzGQUZGgAmCFZ5ND//jE0IfAZ2pcJLibiAe9TKlAnyb+sX/xsLVBHhB+2wrmOzTCH7tm5XQYEDr/VCjbNC94yF1Ce55kc4xJnZPkxA257v5AWOx 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/msg00224.txt.bz2 On Fri, Nov 30, 2012 at 6:13 AM, mathieu lacage wrote: > > $ gcc -fsplit-stack ./test.c -o test > $ ./test > hello 0x7fbecfd58960 > Segmentation fault (core dumped) You neglected to say which version of GCC you are using. I tried your test case with both GCC mainline and the GCC 4.7 branch, and it worked fine. But I am using the gold linker, not GNU ld. > Obviously, the same test will also segfault without -fsplit-stack but > now, it segfaults with an interesting backtrace: I don't really see why this test will segfault without using -fsplit-stack. For me it works fine without -fsplit-stack, which is what I would expect. > 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. That is a crash inside the dynamic linker. I'm not sure why it happened. > 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 ? The detailed documentation on that internal function are in the source code. libgcc/config/i386/morestack.S. That function and __morestack_non_split are the only ones that your application will call directly. There are various other functions involved that are called, directly or indirectly, by __morestack. > 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 ? Yes, provided you are using gold. > 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' You neglected to say which version of gold you are using. In any case, note that you should not invoke gold directly. You should arrange for the GCC driver to invoke it on your behalf. Otherwise you won't get the right files. The way to do this is to install gold under the name "ld" in some directory DIR, and pass the option -BDIR to gcc. You can use gcc -Wl,-debug to see precisely which linker gcc is running, and make sure that it is gold and not GNU ld. > 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 ?. The linker adjusts the code on a function by function basis, based on whether the function calls a non-split-stack function or not. The general scheme is outlined on the wiki page: http://gcc.gnu.org/wiki/SplitStacks . > What happens at runtime ? Does the loader perform a similar check ? (if > so, which loader/version ? The loader does not know anything about split stacks, and it doesn't need to know. > 3) gdb: Does gcc generate the right kind of dwarf information for gdb to > understand how to unwind a stack-split stack ? Yes. > 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 ? I don't have any precise measurements. The cost of code that does not split the stack is low: a few additional instructions per function call. This is unlikely to make any difference except perhaps in a program that is heavily CPU bound and makes lots of function calls in tight loops. However, actually splitting the stack is relatively expensive because it requires a couple of system calls. That can add up pretty quickly if you have a tight loop that winds up needing to split the stack to an unfortunate coincidence of available stack space and the stack requirements of the function being called. Ian