FAQ
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ian Lance Taylor at Jul 10, 2015 at 3:46 pm

    On Fri, Jul 10, 2015 at 8:16 AM, 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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Laboger at Jul 10, 2015 at 4:19 pm
    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?

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Jul 10, 2015 at 4:31 pm

    On Fri, Jul 10, 2015 at 9:18 AM, 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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJul 10, '15 at 3:16p
activeJul 10, '15 at 4:31p
posts4
users2
websitegolang.org

2 users in discussion

Ian Lance Taylor: 2 posts Laboger: 2 posts

People

Translate

site design / logo © 2022 Grokbase