Paolo Bonzini <bonz...@gnu.org> writes:
>> The new libgcc/config/$target-lib.h headers are added to libgcc_tm_file
>> in gcc/config.gcc. I'd rather add them to libgcc/config.host instead so
>> the information is kept local to libgcc.
>
> Did you have any problems doing so?
There weren't any provisions in libgcc/configure.ac similar to
libgcc_tm_file in gcc/configure.ac, so I took the easy way out.
> Long term, it would be even better to do something like this in
> libgcc/config.host:
>
> enable_execute_stack=enable-execute-stack-empty.c
> case $host in
> ...) enable_execute_stack=config/enable-execute-stack-mprotect.c ;;
> ...
> esac
>
> in libgcc/configure.ac:
>
> AC_CONFIG_LINKS(enable-execute-stack.c:$enable_execute_stack)
>
> in libgcc/Makefile.in:
>
> LIB2ADD += enable-execute-stack.c
>
> and drop this hunk altogether from gcc/libgcc2.c:
>
> #ifdef L_enable_execute_stack
> /* Attempt to turn on execute permission for the stack. */
>
> #ifdef ENABLE_EXECUTE_STACK
> ENABLE_EXECUTE_STACK
> #else
> void
> __enable_execute_stack (void *addr __attribute__((__unused__)))
> {}
> #endif /* ENABLE_EXECUTE_STACK */
>
> #endif /* L_enable_execute_stack */
Seems like a plan, but I didn't go in this direction since I couldn't
test anything like this. The various __enable_execute_stack
implementations differ in minor ways that would have to be autoconf'ed.
This should be done by someone with access to the affected platforms.
One other caveat: I don't know if I like grouping the configure support
for the enable-execute-stack.c variants together or would rather keep
all configuration for a single platform (or OS) together. Probably a
matter of taste.
Another question: should we keep the variants in libgcc/config (like
your config/enable-execute-stack-mprotect.c) or at the toplevel (like
enable-execute-stack-empty.c)? At the moment I see a mixture of files
at the libgcc toplevel and others in config.
>> Bootstrapped without regressions on i386-pc-solaris2.11 and
>> sparc-sun-solaris2.11.
>>
>> I've Cc'ed the OS port maintainers of the other affected targets and
>> would appreciate testing/review. An OpenBSD maintainer isn't listed,
>> unfortunately. Also included are the CPU port maintainers for the
>> modified backends.
>>
>> Ok for mainline after a week if no problems occur in testing on the
>> other targets?
>
> It's a good start, but at least you need changes to the documentation; if
I'd thought about it, but refrained since HAVE_ENABLE_EXECUTE_STACK
affects only three cpus. Currently, our documentation of libgcc
configury and macros used is close to non-existant. That's probably for
someone who has implemented this stuff.
> you can make the above work, that would be great as an example of how to
> move stuff to the libgcc toplevel directory.
I'll give it a try, but it might take over the weekend.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
