jikesrvm-researchers-bounces@lists.sourceforge.net wrote on 10/26/2007 01:00:06 AM:

> 1,In the function of hardwareTrapHandler(int signo, siginfo_t *si,
> void *context) of libvm.c(ia32)

>   the line fo 579, there is "stackLimit - 384"
>  line  579  sp = (long unsigned int *)stackLimit - 384;
>  line  580 stackLimit -= VM_Constants_STACK_SIZE_GUARD;
>  why stacklimit minus 384,
> 2 also In the function of hardwareTrapHandler(int signo, siginfo_t
> *si, void *context) of libvm.c(ia32)

> line 560 /* Advance ESP to the guard region of the stack.
>      * Enables opt compiler to have ESP point to somewhere
>      * other than the bottom of the frame at a PEI (see bug 2570).

>      *
>      * We'll execute the entire code sequence for
>      * VM_Runtime.deliverHardwareException et al. in the guard region of the
>      * stack to avoid bashing stuff in the bottom opt-frame.
>      */
>     sp = (long unsigned int *) IA32_ESP(context);

> what's the bug of 2570,i can't find it.

        Looking back at the history of the file, I added this code about 5 1/2 years ago.  The situation it is trying to workaround is that we don't require the opt compiler to always have the ESP register pointing at the bottom of its stackframe.  As a result, if we didn't adjust ESP down before creating a new frame for the hardware trap handler, we could overwrite the current stackframe.

        I don't know where 384 came from.  384 = 256 + 128.  If there was a reason for picking that particular number I can't recall it now and it doesn't appear to be documented anywhere :(

--dave