This is the mail archive of the
mailing list for the GCC project.
Re: Patch RFC: disable block partitioning with split stack
On Fri, Jun 9, 2017 at 3:16 AM, Jan Hubicka <email@example.com> 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.