[Bug go/66870] New: split stack issues on ppc64le and ppc64

["boger at us dot ibm.com" <gcc-bugzilla at gcc dot gnu dot org>]

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.