Mail Archives: djgpp/1995/09/29/12:37:32
> Last question, is there any reason preventing auto-locking of the
> iret/callback wrappers and interrupt stack space in subsequent compiles
> of libc.a? It seems that right after the malloc would be the perfect
> place to go ahead and lock it. For the .beta3 release I went ahead and
> patched the libc sources, are there any side effect I should be aware of?
This should be done. If you have patches to do this, please put them
on ftp.delorie.com in the incoming directory. Everyone has just been too
busy with other things to get to it. I would also suggest locking 4096
bytes after the starting address of the wrapped function. Since most
interrupt routines should be fairly short, I would guess this would
automatically handle 99% of the cases, and locking an extra page of
memory won't hurt anything.
At that point, it would be up to the user to lock any data they touch
or any subroutines they might call (and to make sure their code is less
than 4096 bytes or lock the rest...). This seems like it would not be
too difficult. I also think we need a simple wrapper function that
automatically adds the CS base to this, so something like
__djgpp_lock_memory(void *, unsigned size_in_bytes)
(which could even use the global value declared in sys/nearptr.h to make
it even easier). I think Mat posted a routine that did this once.
- Raw text -