[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	13/11/03 19:00:34

Modified files:
	cm3/m3-sys/m3cc/gcc-4.7/gcc/: config.gcc 

Log message:
	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.