Go patch RFC: Don't mark Go executables as requiring writable stack

[Ian Lance Taylor]

PR 47656 points out that Go programs are often marked as having an
executable stack.  This is incorrect.  Go does use trampolines, but they
are never built on the stack.  They are built on the heap, using
mprotect.  This is necessary because Go closures may be returned from
functions and as such must be heap allocated, not stack allocated.

Currently gcc decides that a program requires an executable stack if it
calls __builtin_init_trampoline.  This turns out to be non-trivial to
change, because that function serves as a marked for LTO as well.  That
is, there is currently no way for the frontend to signal that is
creating a trampoline but that it does not need an executable stack.

This patch fixes the problem by introducing a new builtin function
__builtin_init_heap_trampoline.  This is a middle-end change so it is
covered under my maintainership.  I also believe it is quite safe.
However, given that we are in stage 4 I would like to ask the release
managers if this is OK to put in.  It fixes a user-reported bug, but the
bug is technically not a regression because it has never actually worked
correctly.

Bootstrapped and ran full testsuite on x86_64-unknown-linux-gnu.  OK to
commit?

Ian


2012-01-27  Ian Lance Taylor  <iant@google.com>

	PR go/47656
	* builtins.def (BUILT_IN_INIT_HEAP_TRAMPOLINE): Define.
	* builtins.c (expand_builtin_init_trampoline): Add onstack
	parameter.  Change caller.
	(expand_builtin): Handle BUILT_IN_INIT_HEAP_TRAMPOLINE.
	* tree.c (build_common_builtin_nodes): Declare
	__builtin_init_heap_trampoline.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.patch
Type: text/x-diff
Size: 5297 bytes
Desc: patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120127/5e6fcd0d/attachment.bin>