<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'> > Mistaking the function's real code for a closure is a lot less likely <BR> > than mistaking the function's real code for a trampoline. A trampoline <BR><BR>
What is the danger in "mistaking" "real code" for a "trampoline"?<BR>
They are both "real code".<BR>
The differences are:<BR>
- trampoline has limited lifetime -- unless it is heap allocated and garbage collected <BR>
("real code" also has "limited lifetime", but relatively much longer, if code can be unloaded, which it can be in many environments) <BR>
- the "real code" of nested functions has a different calling convention than "real code" for non nested functions; it has an extra parameter "somewhere", for the "static link"; in gcc C nested functions on Cygwin/x86, this is in ecx <BR>
<BR>
What do folks think about putting trampolines in executable garbage collected heap?<BR>
I think that's inefficient but I'm usually in the minority here regarding the heap being inefficient.<BR>
<BR>
One way or another, gcc makes C nested functions fairly portable, except Apple's gcc on Darwin.<BR>
Portability of -1 as a marker denoting "not code" is also dubious.<BR>
<BR>
I think it stinks either way.<BR>
<BR>
Anyone think coming up with "better" per-architecture markers is reasonable?<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Mon, 26 May 2008 15:47:53 -0500<BR>> From: rodney.bates@wichita.edu<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?<BR>> <BR>> <BR>> <BR>> Jay wrote:<BR>> > It stinks either way imho.<BR>> > The portability is handled, somehow or another, by gcc's support for <BR>> > nested functions.<BR>> > For example on OpenBSD, they call mprotect to make the trampoline <BR>> > executable -- expensive! and leaves a bit of a security hole.<BR>> > On Linux you can sometimes mark the .exe as needing an executable stack <BR>> > or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.<BR>> > ATL on Windows puts trampolines in the heap and specifically makes them <BR>> > executable -- since the heap isn't necessarily executable either.<BR>> > The -1 marker is also a bit of a portability problem but I guess in <BR>> > practise it works out.<BR>> <BR>> Using trampolines would make this problem worse, perhaps much worse.<BR>> Mistaking the function's real code for a closure is a lot less likely<BR>> than mistaking the function's real code for a trampoline. A trampoline<BR>> is, after all, always valid machine code on the executing processor.<BR>> Not necessarily so for -1.<BR>> <BR>> > I'd be curious to see how it decodes on various processors.<BR>> > <BR>> > - Jay<BR>> ><BR>> -- <BR>> -------------------------------------------------------------<BR>> Rodney M. Bates, retired assistant professor<BR>> Dept. of Computer Science, Wichita State University<BR>> Wichita, KS 67260-0083<BR>> 316-978-3922<BR>> rodney.bates@wichita.edu<BR><BR></body>
</html>