[Bug go/107491] New: GccGo stack not resizing on Solaris

[Bug go/107491] New: GccGo stack not resizing on Solaris

[jakub.kulik at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

            Bug ID: 107491
           Summary: GccGo stack not resizing on Solaris
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: jakub.kulik at oracle dot com
  Target Milestone: ---

Created attachment 53809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53809&action=edit
simple program with recursion that break on Solaris

Question regarding gccgo and stack sizes on Solaris (and other non GNU/Linux
systems).

When I run a code with (not that deep) recursion (example attached) on Solaris,
it segfaults as it overflows the stack. I checked with gdb on both Linux and
Solaris and Linux is calling `__morestack` once in a while and Solaris does
not. IIUIC, __morestack allocates additional stack when compiled with
`-fsplit-stack`, which is "currently only supported on GNU/Linux".

As for my question, is this behavior (segfault after 4MB stack is exhausted)
expected or is there a different stack resize/overflow prevention on non
`-split-stack` platforms that might not be working correctly on Solaris?

This is on Oracle Solaris 11.4 and gccgo shipped with gcc 10.4, 11.3 and 12.1.

(Golang is fine but that is to be expected as they implement all this in a
different way).

[Bug go/107491] Gccgo stack not resizing on Solaris

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-11-01
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The __morestack mechanism is a pure Linux hack, i.e. it is not implemented on
any other operating systems.

[Bug go/107491] Gccgo stack not resizing on Solaris

[jakub.kulik at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #2 from Jakub Kulik <jakub.kulik at oracle dot com> ---
That's what I thought, but I am not sure whether there is supposed to be a
different mechanism on other platforms or whether the 4MB stack cap per thread
is the maximum I can get on non Linux platform.

[Bug go/107491] Gccgo stack not resizing on Solaris

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #3 from Ian Lance Taylor <ian at airs dot com> ---
The stack size on a system that does not support -fsplit-stack is set by
StackMin in libgo/runtime/stack.c.  There is currently no way to override the
default value of 4MB, but we could probably add one based on an environment
variable.

(Or we could support -fsplit-stack on Solaris if there is an available slot
accessible via the TLS segment register.  On Linux x86_64 we use %fs:0x70.)

[Bug go/107491] Gccgo stack not resizing on Solaris

[jakub.kulik at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #4 from Jakub Kulik <jakub.kulik at oracle dot com> ---
Thanks for the confirmation.

-fsplit-stack on Solaris would be nice, but it's as simple as designating a TLS
accessible slot, right? We have our own linker on Solaris and don't use gold,
and I am not how feasible it would be to add functionality similar to that of
gold.

I do like the idea of adjustable min size with an environment variable because
that should not be a big change, and all platforms can use it. It's not really
the best solution, but better than nothing, I guess.

[Bug go/107491] Gccgo stack not resizing on Solaris

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #5 from Ian Lance Taylor <ian at airs dot com> ---
Good point, I did forget about using gold or lld.  Sorry.

[Bug go/107491] Gccgo stack not resizing on Solaris

[jakub.kulik at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #6 from Jakub Kulik <jakub.kulik at oracle dot com> ---
So, I tested it with the following simple change and it works nicely:

--- gcc-12.2.0/libgo/runtime/proc.c
+++ gcc-12.2.0/libgo/runtime/proc.c
@@ -798,7 +798,15 @@ runtime_malg(bool allocatestack, bool si
        }
        newg = allocg();
        if(allocatestack) {
-               stacksize = StackMin;
+               char* res = getenv("GCCGO_MIN_STACK_SIZE");
+               if (res) {
+                       stacksize = atoi(res) * 1024 * 1024;
+
+                       if (stacksize < StackMin)
+                               stacksize = StackMin;
+               } else {
+                       stacksize = StackMin;
+               }
                if(signalstack) {
                        stacksize = 32 * 1024; // OS X wants >= 8K, GNU/Linux
>= 2K
 #ifdef SIGSTKSZ

As said, it's not the right solution, but it's an improvement.

As for the split stack, I am wondering whether it is possible to do it without
linker support? IIUIC, gold makes sure then when split stack code calls a non
split stack one, much bigger stack is available. But if we make sure that the
headroom is big enough all the time, then it might work without the linker
support as well.

[Bug go/107491] Gccgo stack not resizing on Solaris

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #7 from Ian Lance Taylor <ian at airs dot com> ---
If we use an environment variable, we should probably use the existing GODEBUG
variable.

Making the stack headroom large enough all the time should be possible.  It
will burn a lot of memory on stacks but maybe that is OK.

[Bug go/107491] Gccgo stack not resizing on Solaris

[jakub.kulik at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #8 from Jakub Kulik <jakub.kulik at oracle dot com> ---
Sure, this was just a quick first test. That said, GODEBUG is slightly more
complex - is there an example of a C code where GODEBUG variables are being
used you can point me to (I found only go sources with anything GODEBUG
related)?

As for the split stack, I will try looking into it and see if it works. Having
overhead might solve the issue with no linker support, but it's indeed pretty
wasteful (and might break what works currently)...

[Bug go/107491] Gccgo stack not resizing on Solaris

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #9 from Ian Lance Taylor <ian at airs dot com> ---
I would suggest adding a new field to the GODEBUG parsing in
go/runtime/runtime1.go and then calling a new C function defined in
libgo/runtime/proc.c to store the value in a C static variable.

[Bug go/107491] Gccgo stack not resizing on Solaris

[jakub.kulik at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #10 from Jakub Kulik <jakub.kulik at oracle dot com> ---
Created attachment 53935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53935&action=edit
Proposed patch with configurable minimal stack size

[Bug go/107491] Gccgo stack not resizing on Solaris

[jakub.kulik at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #11 from Jakub Kulik <jakub.kulik at oracle dot com> ---
So, I looked into it and with the patch attached above seems to work as
expected. Stack can be resized like this `GODEBUG=minstacksize=32 ./test`.

[Bug go/107491] Gccgo stack not resizing on Solaris

[jakub.kulik at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491

--- Comment #12 from Jakub Kulik <jakub.kulik at oracle dot com> ---
One thing that is still slightly limiting is that the stack size cannot be
changed e.g. for individual tests when running the libgo test suite.

It might be nice to have some exported interface, such as the already existing
SetMaxStack() [1], although I do understand that that would be a bigger change
and would make the code using it golang incompatible, which might be a problem.

There is probably not much to do about this - I just wanted to mention this
limitation.

[1] https://pkg.go.dev/runtime/debug#SetMaxStack