This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Nested functions


Marco Gerards <mgerards@xs4all.nl> writes:

> Sorry, I should choose my words more carefully.  Are nested functions
> being deprecated?

No.  Nested function support is required in any case to support
languages other than C/C++.  Given that the backend support is
required, there is no particular plan to remove the extension from
C/C++.

> Are there plans to use something else than an
> executable stack to implement trampolines?

Not I am aware of.  Efficient, general, trampolines require the
ability to generate code on the fly.  That requires a section of
memory which is both writable and executable.  It doesn't have to be
the stack, but in general any approach along those lines is going to
run afoul of people concerned about security holes.

The basic problem, of course, is that taking the pointer of a nested
function requires storing both a code address (the function) and a
data address (the stack frame).  But a function pointer in a normal C
implementation is only a code address.  If all you have is a code
address, where do you store the data address?

One possibility would be to provide a fixed number of trampolines
which reference particular locations in memory.  They would be
allocated and deallocated based on stack usage.  That would handle
most real programs, but there would always be valid programs which
would crash under this type of implementation.  I'm not aware of
anybody working on this type of implementation.  (Something along
these lines may be required to support trampolines on Harvard
architectures, in which memory is by definition never both writable
and executable.)

Here is an approach that might work in the general case on a Unix
system.  When we need to create a trampoline, use mmap with PROT_WRITE
to create a new anonymous page.  Copy the trampoline template into it,
and adjust it as required.  Then use mprotect to remove PROT_WRITE and
add PROT_EXEC.  Then continue as usual.  The obvious drawback is
requiring two system calls for every trampoline you create.  Other
than that, I think it ought to work.  I'm not aware of anybody working
on this type of implementation either.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]