Re: [Tinycc-devel] Some feedback

[Evan Langlois]

On Thu, 2005-09-01 at 21:16 -0700, Daniel P. Stasinski wrote:
> On 9/1/05, Marcelo Jimenez <address@hidden> wrote:
> > Daniel, did you see the patch I wrote about exec-shield? I have FC4
> > and -run does not segfault. Try as root:
> 
> Ok, I have an idea.  Please tell me if it's a bad idea but it will get
> the -run option to work regardless of exec-shield.  I tested it with a
> quick dirty proof of concept hack.
> 
> Make it a compile time option that rather than exec the code by
> jumping to it in memory, instead write it to a tmp file, execlp() it,
> delete the tmp file and return the status.

No - that could be much slower.

Instead, use mmap() with PROT_EXEC.  I haven't looked at the tiny-cc
code, but you could use mmap() with a file backing when writing an
executable to disk as well - could speed things up there and maybe allow
for code reuse when not writing the file to disk.  I believe the
quickest hack would be to use mmap() on the already existing memory area
that the program is going to execute from (should work I think, but not
tried that).  I believe mmap() should be able to add the execute bit to
the page tables, and then exec-shield shouldn't hurt things.  That
assumes there aren't bugs in exec-shield that prevent mmap() from
altering the mapping.

> 
> It works for me.
> 

Dump memory to a file, allocate disk space, free memory, load memory
with file, do dynamic linking, free disk space.   Hmm ... compared to
"execute at this address".   Have you done any speed test comparisons?
I would think caching would make this very fast regardless with the
added dynamic linking stage possibly causing some slowdown ... until you
hit a system that is low on RAM ... you'd have a race condition where
the cache could be cleared before you can read the file back in.  For
small programs its likely not a big issue, but I'm from the old school
of thought where every last clock cycle counts :)