From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57827 invoked by alias); 14 Jul 2015 14:31:36 -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 57208 invoked by uid 48); 14 Jul 2015 14:31:30 -0000 From: "boger at us dot ibm.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/66870] New: split stack issues on ppc64le and ppc64 Date: Tue, 14 Jul 2015 14:31:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new 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: boger at us dot ibm.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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone cf_gcctarget attachments.created Message-ID: 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/msg01137.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 Bug ID: 66870 Summary: split stack issues on ppc64le and ppc64 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: boger at us dot ibm.com CC: amodra at gmail dot com, cmang at google dot com, schwab@linux-m68k.org Target Milestone: --- Target: ppc64le, ppc64 Created attachment 35977 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35977&action=edit Detect no_split_stack attribute when generating split stack prologue. There are a few issues to be resolved with the split stack implementation on ppc64le, ppc64, and disabling it correctly when building for ppc (32 bit BE). 1) When building on a system with glibc >= 2.18 and doing a multilib build, the ppc 32 build incorrectly has the split stack flag set, causing an error during the build. This was identified in gcc-patches and a proposed fix suggested: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00963.html https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01038.html (Note: this seems to fix the problem but I don't understand why. The setting of the flag was simply moved past a few statements and I don't see why that should affect the outcome, since the opt argument passed in this case is &global_options.) 2) For functions with the _no_split_stack attribute set, the split stack code generation was not always correct on ppc64le & ppc64. I have a patch for that which is attached. This problem was not obvious when building on ppc64le (where most of my testing was done) but occurs often when built on ppc64. 3) The file gcc/go/gospec.c generates options to be passed to the linker based on a define of #TARGET_CAN_SPLIT_STACK but this define is never set for a build for ppc64le or ppc64. The first occurrence in the function lang_specific_driver generates the fsplit-stack option when calling the linker, the second occurrence sets -Wl,-u pthread_create. I believe the setting of this define has to be consistent with the result of rs6000_supports_split_stack in gcc/common/config/rs6000/rs6000-common.c -- but that function depends on the setting of rs6000_isa_flags which has not been updated by the time lang_specific_driver is called. I'm assuming it is wrong for these options not to be generated and passed to the linker when using split stack? 4) I believe we always want to use the gold linker with gccgo on ppc64le and ppc64 and probably ppc is OK too. This is necessary to get the minimum storage allocated for goroutines (which is the whole point of providing this option) and also prevents errors with split stack that could happen in some cases. I've exchanged some notes with iant on this topic and he suggested this: The -fuse-ld=gold option is newer than gccgo. I suppose it would be nice if: * the GCC configure process checks whether -fuse-ld=gold works; if so: * -fuse-ld=gold is passed to the libgo configure/build >>> I think this is already done by the libgo configure -- or at least it attempts to see if the linker associated with the gccgo it is using to build libgo supports split stack and then sets the flag libgo_cv_c_linker_supports_split_stack and that makes it all work. So if we build gccgo with the gold linker as its linker then this should just work. * -fuse-ld=gold is used by default by the gccgo driver program >>> Not sure how best to do this just for gccgo and not the other gcc compilers. I can keep looking but if anyone has a suggestion let me know. There are probably other creative ways to do this by setting spec defines that are only available for ppc64le, ppc64 builds but haven't figured it out yet.