|
From: Duncan S. <bal...@fr...> - 2005-05-19 10:56:01
|
Hi Julian, the pain is already less!
> Let me see if I understand the landscape correctly.
>
> The problem is that ada (and nested C/C++ fns, with gcc) create small
> bits of code on the stack and then run them. V fails to notice when on
> of these small bits of code gets re-made, and so may wind up using out
> of date translations.
that is my understanding.
> So we can easily enough generate self-checking translations. A problem
> is, since self-checking translations are expensive to run, we want to
> make as few as possible. That means having a good heuristic for deciding
> when to do so. The currently postulated heuristic is to make a self-
> checking translation for code within some small offset of the stack
> pointer. Ideally the heuristic should say "yes" as infrequently as
> possible, but it should also never miss any such cases either.
>
> Is that correct? Any other things I need to take into account?
On i386 (32 bit), trampolines have the following properties:
(1) they are always aligned on 16 byte boundaries
(2) they always consist of the following two instructions:
mov #STATIC,ecx
jmp FUNCTION
I got this from gcc/doc/tm.texi and gcc/config/i386/i386.h.
In gcc/config/i386/i386.c you can find x86_initialize_trampoline
which generates 0xb9 (mov ecx,imm32) and 0xe9 (jmp rel32).
II guess if you look for jumps to 16 byte aligned guys holding
those instructions near the stack pointer, then the number of
false positives will be small. Of course this is gcc specific -
do other compilers do this kind of thing too?
All the best,
Duncan.
|