Re: gcc-4.0.1 = nested functions are not supported on MacOSX?
Re: gcc-4.0.1 = nested functions are not supported on MacOSX?
- Subject: Re: gcc-4.0.1 = nested functions are not supported on MacOSX?
- From: Alastair Houghton <email@hidden>
- Date: Mon, 14 Nov 2005 14:43:33 +0000
On 11 Nov 2005, at 07:48, Eric Albert wrote:
On Nov 10, 2005, at 10:24 PM, Daryn wrote:
The new xcode 2.2's gcc 4.0.1 compiler update has apparently
dropped support for nested functions. Apple's release notes for
gcc do not even mention this change... :(
Before I downgrade to gcc 4.0, is there a command line option to
re-enable nested functions?
Why were they disabled? Are they going to be re-enabled?
gcc's implementation of nested functions involves placing code on
the stack and then executing it. Stack execution is a common
operation in malicious code, particularly as a side effect of
buffer overflows. While the proper fix is of course to not make
buffer overflows possible in the first place, disabling stack
execution decreases the likelihood that a buffer overflow or other
stack-smashing attack will be exploitable.
In future releases of Mac OS X, we may disable stack execution.
(Obviously we'll have to keep binary compatibility in mind when or
if we do that.) Nested functions were disabled to help prepare for
that change.
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.
As someone who's just hit this problem (we were using nested
functions in a few places where we get called-back from third-party
code with no context argument), it's very irritating that you guys
disabled nested functions without any warning (or with very little,
anyway). Also, you do know that there are macros you can define in
the GCC back-end to make trampolines work on systems with non-
executable stacks, right? The easiest fix would be to define the
ENABLE_EXECUTE_STACK and INITIALIZE_TRAMPOINE macros to call a system
routine to make the stack executable; that way, only programs/threads
that used nested functions would have executable stacks. Or if you
wanted to avoid executable stack pages altogether, you can do your
own thing using TRAMPOLINE_ADJUST_ADDRESS.
In any case, disabling nested functions because trampolines are stack-
based by default seems like the wrong solution. Even without
changing GCC, you could work around the problem of executing
trampolines in the stack area... for instance, the Linux support for
non-executable stacks includes a couple of mechanisms for making that
work.
I also think it's worth pointing out that some of the other languages
supported by the GCC toolchain (for instance, Ada---which is now in
the core sources---and Pascal) include nested functions as a language
feature. That being the case, it seems unlikely that nested
functions will still need to be disabled by the time a version of OS
X comes out with a non-executable stack (unless you were planning on
doing this in a minor version release?). Plus, disabling them in
Apple's builds of the C and C++ compilers isn't going to affect
people using Ada, Pascal or Modula-3, because they have to build
their own and disabling the language extension in the C/ObjC/C++
front-ends won't affect the use of trampolines in those compilers.
Similarly, there will be other, non-GCC compilers, that use stack-
based trampolines as an implementation technique... Basically, I
don't see how disabling them actually helps (although perhaps tagging
executables to say whether they use stack-based trampolines or not
might...)
Anyway, for now, I'm going to go through our code removing any use of
nested functions, but I can't say I'm particularly happy about it,
especially as the alternatives in some cases are harder to follow and
debug.
Kind regards,
Alastair.
p.s. I have filed a bug report about this.
--
http://www.alastairs-place.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden