gccgo split stack implementation

[lab...@linux.vnet.ibm.com]

I'm trying to understand how the split stack implementation in gccgo should work.

Recently the split stack support was added upstream in gccgo for ppc64le.  This causes the split stack flag to be enabled by default in gccgo, and as a result, the libgo that is built based on USING_SPLIT_STACK being defined, which enables all the split stack specific code in libgo, as well as building all other code in libgo with the -fsplit-stack option.

What happens if someone builds using gccgo and the split-stack version of libgo but sets the -fno-split-stack flag?  Is this an issue?  Should there be two versions of libgo built, or is it OK to use this libgo with -fno-split-stack compiles?

I would also like some detail as to when the gold linker is really needed.  In this document https://gcc.gnu.org/wiki/SplitStacks it says you need the gold linker for full functionality, but there are no details as to what that means.  I see the LINKER_SUPPORTS_SPLIT_STACK define within libgo affecting the amount of storage allocated for the stack for each goroutine but that is a gccgo build time attribute and not necessarily what is available where the gccgo is installed and used.

[Ian Lance Taylor]

On Fri, Jul 10, 2015 at 8:16 AM, <lab...@linux.vnet.ibm.com> wrote:
>
> I'm trying to understand how the split stack implementation in gccgo should
> work.
>
> Recently the split stack support was added upstream in gccgo for ppc64le.
> This causes the split stack flag to be enabled by default in gccgo, and as a
> result, the libgo that is built based on USING_SPLIT_STACK being defined,
> which enables all the split stack specific code in libgo, as well as
> building all other code in libgo with the -fsplit-stack option.
>
> What happens if someone builds using gccgo and the split-stack version of
> libgo but sets the -fno-split-stack flag? Is this an issue? Should there
> be two versions of libgo built, or is it OK to use this libgo with
> -fno-split-stack compiles?

It should be fine to compile with -fno-split-stack and link with a
libgo built with -fsplit-stack. In a sense, that is what happens with
any program, since the startup code (crt0.o, etc.) is not compiled
with -fsplit-stack. The stack can start splitting at any point. The
stack size is automatically recorded at program startup, and each
thread startup. At least, that is how the x86 support works, and I
assume the PPC support is similar.

> I would also like some detail as to when the gold linker is really needed.
> In this document https://gcc.gnu.org/wiki/SplitStacks it says you need the
> gold linker for full functionality, but there are no details as to what that
> means. I see the LINKER_SUPPORTS_SPLIT_STACK define within libgo affecting
> the amount of storage allocated for the stack for each goroutine but that is
> a gccgo build time attribute and not necessarily what is available where the
> gccgo is installed and used.

The gold linker detects calls from split-stack code to non-split-stack
code, and rewrites the function header to force a large stack segment
to be allocated. When not using the gold linker, calls from
split-stack code to non-split-stack code will just have whatever is
left of the current stack segment, which, of course, may not be large
enough.

This is discussed, sort of, on the wiki page in the "Backward
compatibility" section. The steps that say that the linker does this
or that only happen if the linker is gold.

You're right that LINKER_SUPPORT_SPLIT_STACK does not correctly handle
the case where the linker is changed between gccgo build and gccgo
use. I don't think that is a common case for anybody who isn't
actively working on the tools.

Ian

[lab...@linux.vnet.ibm.com]

I've looked at the split stack support in x86 for gccgo, but I don't see anything that would cause it to use the gold linker.  Does that mean the user is expected to add the -fuse-ld=gold option when building with gccgo on x86 so that it links with the gold linker and avoids any possible issues with split stack?

[Ian Lance Taylor]

On Fri, Jul 10, 2015 at 9:18 AM, <lab...@linux.vnet.ibm.com> wrote:
>
> I've looked at the split stack support in x86 for gccgo, but I don't see
> anything that would cause it to use the gold linker. Does that mean the
> user is expected to add the -fuse-ld=gold option when building with gccgo on
> x86 so that it links with the gold linker and avoids any possible issues
> with split stack?

In the complex GCC ecosystem the linker is separate from the compiler.
GCC can't assume that gold is available at all. When building gccgo
myself, I configure using --with-ld=/path/to/gold.

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
* -fuse-ld=gold is used by default by the gccgo driver program

Ian

> On Friday, July 10, 2015 at 10:16:37 AM UTC-5, lab...@linux.vnet.ibm.com
> wrote:
>>
>> I'm trying to understand how the split stack implementation in gccgo
>> should work.
>>
>> Recently the split stack support was added upstream in gccgo for ppc64le.
>> This causes the split stack flag to be enabled by default in gccgo, and as a
>> result, the libgo that is built based on USING_SPLIT_STACK being defined,
>> which enables all the split stack specific code in libgo, as well as
>> building all other code in libgo with the -fsplit-stack option.
>>
>> What happens if someone builds using gccgo and the split-stack version of
>> libgo but sets the -fno-split-stack flag? Is this an issue? Should there
>> be two versions of libgo built, or is it OK to use this libgo with
>> -fno-split-stack compiles?
>>
>> I would also like some detail as to when the gold linker is really needed.
>> In this document https://gcc.gnu.org/wiki/SplitStacks it says you need the
>> gold linker for full functionality, but there are no details as to what that
>> means. I see the LINKER_SUPPORTS_SPLIT_STACK define within libgo affecting
>> the amount of storage allocated for the stack for each goroutine but that is
>> a gccgo build time attribute and not necessarily what is available where the
>> gccgo is installed and used.
>

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.