Re: [Swarm-Support] Re: Swarm 2.2 on Intel (and PPC) Mac OSX Tiger

[Marcus G. Daniels]

Bill Northcott wrote:
> The problem is that at least one hardware manufacturer has made it 
> clear they intend to disable the low level mechanisms used by the 
> compiler to implement the source code, and the gcc developers say 
> there is no intention to write a different implementation in the compiler.
It's good to have memory regions that can be made non-executable (thanks 
to NX/XD bits on Intel/AMD CPUs). It would be one thing if before making 
a change like this Apple enhanced the compiler to activate stack 
executability as needed (Linux can), or to enhance manage the 
trampolines in another way.  But as it often does with Apple, market 
forces were considered, and then laziness prevailed. 

http://developer.apple.com/technotes/tn2006/tn2161.html
http://lists.apple.com/archives/Xcode-users/2005/Nov/msg00402.html

And they go on to say:

"As for whether nested functions will be re-enabled, if someone 
contributes a patch to GCC to change the nested function implementation 
to not rely on stack execution, presumably there'd be a chance they'd be 
re-enabled."

> 4.  As a proper fix, we need an autoconf test to see if the compiler 
> accepts nested functions and use that as the default able to be 
> overridden by the builder.
This is like any situation where a vendor provides a broken compiler, 
kernel, or runtime.   Autoconf is a helpful way to adapt to the lossage 
(especially if the lossage spreads to other vendors) but one hopes such 
macros find their way into autoconf itself.  As a sort of allocution of 
the vendor(s) sins, if nothing else.   But a "fix" is only needed when 
something is broken, and Swarm isn't.