[M3commit] CVS Update: cm3
jkrell at elego.de
Sun Nov 3 19:00:34 CET 2013
Changes by: jkrell at birch. 13/11/03 19:00:34
We don't need exec-stack.h as we don't create trampolines, as we
implement nested functions a different way.
Perhaps we should reuse gcc's way.
There is no good solution there though. gcc's is very flawed and
ours is too.
In the gcc case, they require producing executable code at runtime,
on the stack, which these days/decades has gotten more and more difficult
in the face of "security".
In our code, we require that function pointers aren't necessarily
the same "flat" thing as in C/C++. For us, whenever we go to
call a function pointer, we first read the bytes therein and look
for a marker integer value of -1, and if we see it, we interpret
the following integers as a struct -- frame pointer and actual pointer.
The problem with this approach is, besides being slower, it
depends on -1 being invalid code, which really isn't clearly correct.
The marker value and size should probably be target-specific.
For example, most 64bit targets should have a 4 byte marker.
i.e. most targets have a 4 byte instruction.
The read should avoid crossing a page, which is easy for non-x86 targets.
x86: maximum instruction size is 15 bytes and instructions can cross a page.
Imagine a function near the end of a page, at the end of a valid virtual
address range. The function might end before the end of the page,
but the check for a closure could read beyond the end of page
and access violate.
More information about the M3commit