Seems like a plan, but I didn't go in this direction since I couldn't
test anything like this.
As long as you test the general configury on 1-2 platforms, it's not any
less tested than what you have now.
The various __enable_execute_stack
implementations differ in minor ways that would have to be autoconf'ed.
Just select them by $host.
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.
In case it wasn't clear, I was proposing the latter.
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.
I would put them under config/ unless they are platform-independent.
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.
True, OTOH HAVE_ENABLE_EXECUTE_STACK is a target macro, and those are
well documented. Just say that it has to be defined if libgcc provides
a non-trivial implementation of __enable_execute_stack; it doesn't need
to delve into how to hack libgcc.
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.
Take your time, we're in stage1 now.
Paolo
