[build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

Joseph S. Myers joseph@codesourcery.com
Tue Jun 7 15:20:00 GMT 2011


On Mon, 6 Jun 2011, Rainer Orth wrote:

> Paolo Bonzini <bonzini@gnu.org> writes:
> 
> >> * Except for Darwin, the code uses TRAMPOLINE_SIZE.  This only exists in
> >>    the backend headers.  While it could be duplicated somewhere in the
> >>    libgcc configury, I'd rather propose that gcc define
> >>    __TRAMPOLINE_SIZE__ (in gcc/c-family/c-cppbuiltin.c (c_cpp_builtins)
> >>    to avoid this.  On PowerPC Darwin, one cannot use TRAMPOLINE_SIZE
> >>    definition right now since the macro calls the rs6000_trampoline_size
> >>    function in rs6000/rs6000.c.  This would be solved nicely by
> >>    __TRAMPOLINE_SIZE__.
> >
> > Good idea.
> 
> Included in the revised patch below.  This part will need Joseph's approval.

Is this definition ever going to be of use to user code, or even to system 
headers?  It looks purely like an implementation detail rather than 
something meaningful for users.  That would tend to suggest conditioning 
it on the proposed new -fbuilding-libgcc option that I suggested in 
<http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01206.html>.  (There are a 
*lot* of target macros that are in a similar position - see the list under 
"used by the compiler itself and libgcc" in 
<http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration>.  Even if we could 
define and document public semantics for corresponding predefined macros, 
I don't think they would be of practical use to users of GCC, so for most 
of them I expect defining __LIBGCC_<macro>, only if -fbuilding-libgcc, is 
the best way of eliminating the dependence on host tm.h without making 
implementation details visible to users of GCC.)

So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if 
-fbuilding-libgcc.

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list