On Fri, Jun 9, 2017 at 3:16 AM, Jan Hubicka <hubi...@ucw.cz> wrote: > >> code compiled with -fsplit-stack, if the cold partition calls a >> function that is not compiled with -fsplit-stack (such as a C library >> function). The problem is that when the linker sees a split-stack >> function call a non-split-stack function, it adjusts the function >> header to request more stack space. This doesn't work if the call is >> in the cold partition, as the linker doesn't know how to find the >> header to adjust. You can see this by trying to build the Go library >> using the gold linker with this patch. > > If code does not work, I wonder why we let user to overwrite the default > by hand? In other cases we drop the flag with inform message.
My thinking here is that there is no fundamental reason that the code does not work, and the actual problem does not lie in GCC but rather in the linker (specifically, gold). It's possible in principle to fix gold to make this work, and someone who is using a fixed gold could then direct GCC to take advantage of this optimization (and later after that version of gold is wide-spread enough we can change GCC to drop this patch). > Also bb-reorder knows how to prevent landing pads to go to different sections, > so perhaps same machinery can be used to prevent splitting blocks having > calls that needs linker adjustments? Unfortunately I don't see how that is possible in general, as the code that needs adjustment is cases where code compiled with -fsplit-stack calls functions compiled without -fsplit-stack. By definition those calls are to functions defined in other compilation units, and the compiler simply doesn't know whether they will be compiled with -fsplit-stack or not. Only the linker knows. Ian
