From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122488 invoked by alias); 14 Jul 2015 17:53:04 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 121641 invoked by uid 48); 14 Jul 2015 17:53:00 -0000 From: "ian at airs dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/66870] split stack issues on ppc64le and ppc64 Date: Tue, 14 Jul 2015 17:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ian at airs dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-07/txt/msg01148.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #3 from Ian Lance Taylor --- > In gcc.c there is STACK_SPLIT_SPEC which sets --wrap=pthread_create in the LINK_COMMAND_SPEC if -fsplit-stack is set. Is there a reason there are 2 different split stack dependent link options are being set in two different ways? Sort of. All uses of -fsplit-stack can and should pass -Wl,--wrap=pthread_create to the linker. That option does nothing if the program is not threaded. If the program is threaded it will cause the code in libgcc/generic-morestack-thread.c to be used. All uses of -fsplit-stack and -static for threaded code should pass -Wl,-u,pthread_create to the linker. Otherwise, in some cases, we may not pull in the threading functions we need. But, unlike the --wrap option, if the program is not threaded, and not linked against -lpthread, this option will cause the link to fail. Go programs are always threaded, so it's safe to add this in gospec.c. It's not safe to add it in a link spec in gcc.c, unless we have some way of determining from the link spec whether the program is threaded. (There is some discussion of why this is needed at https://groups.google.com/d/msg/golang-nuts/y2RIy0XLJ24/uFIdOE8wPL8J .)