¿Qué contiene cada entrada en la estructura Jmp_buf?

Question

Estoy ejecutando Ubuntu 9.10 (Karmic Koala) y eché un vistazo al jmp_buf estructura que es simplemente una matriz de 12 entradas.cuando uso setjmp, y pasar en un jmp_buf estructura: 4 de 12 entradas se guardan.Estas 4 entradas son el puntero de pila, el puntero de marco, el contador de programa y la dirección de retorno.¿Para qué sirven las otras 8 entradas?¿Dependen de la máquina?¿Es otra entrada el registro base de la tabla de segmentos?¿Qué más se necesita para restaurar adecuadamente el entorno de un subproceso/proceso?Revisé la página de manual y otras fuentes, pero no pude encontrar el código ensamblador para setjmp.

Answer 1

En MacOS X 10.6.2, el encabezado <setjmp.h> termina usando <i386/setjmp.h>, y allí dice:

#if defined(__x86_64__)
/*
 * _JBLEN is number of ints required to save the following:
 * rflags, rip, rbp, rsp, rbx, r12, r13, r14, r15... these are 8 bytes each
 * mxcsr, fp control word, sigmask... these are 4 bytes each
 * add 16 ints for future expansion needs...
 */
#define _JBLEN ((9 * 2) + 3 + 16)
typedef int jmp_buf[_JBLEN];
typedef int sigjmp_buf[_JBLEN + 1];

#else

/*
 * _JBLEN is number of ints required to save the following:
 * eax, ebx, ecx, edx, edi, esi, ebp, esp, ss, eflags, eip,
 * cs, de, es, fs, gs == 16 ints
 * onstack, mask = 2 ints
 */

#define _JBLEN (18)
typedef int jmp_buf[_JBLEN];
typedef int sigjmp_buf[_JBLEN + 1];

#endif

Probablemente encuentre requisitos similares en Linux: el jmp_buf contiene suficiente información para almacenar el estado necesario. Y, para usarlo, realmente no necesita saber qué contiene; todo lo que necesita hacer es confiar en que los implementadores lo hicieron correctamente. Si desea alterar la implementación, debe comprenderla, por supuesto.

Tenga en cuenta que setjmp y longjmp son muy específicos de la máquina. Lea & Quot; The Standard C Library & Quot; para una discusión de algunos de los problemas involucrados en su implementación. Los chips más modernos hacen que sea más difícil de implementar realmente bien.

Answer 2

setjmp / longjmp / sigsetjmp dependen en gran medida de la arquitectura de la CPU, el sistema operativo y el modelo de subprocesos. Las dos primeras funciones famosas (o infamemente & # 8212; dependiendo de su POV) aparecieron en el núcleo original de Unix como & Quot; estructurado & Quot; forma de desconectarse de una llamada fallida del sistema, como un error de E / S u otras situaciones desagradables.

Los comentarios de la estructura en /usr/include/setjmp.h (Linux Fedora) dicen Entorno de llamada, más posiblemente una máscara de señal guardada. Incluye /usr/include/bits/setjmp.h para declara que jmp_buf tiene una matriz de seis entradas de 32 bits, aparentemente específicas para la familia x86.

Si bien no pude encontrar otra fuente que no sea implementación de PPC , los comentarios allí sugieren razonablemente que la configuración de FPU debe guardarse. Eso tiene sentido, ya que si no se restaura el modo de redondeo, el tamaño de operando predeterminado, el manejo de excepciones, etc. sería sorprendente.

Es típico de los ingenieros de sistemas reservar un poco más de espacio del que realmente se necesita en dicha estructura. Unos pocos bytes adicionales no son nada para sudar & # 8212; especialmente teniendo en cuenta la rareza de los usos reales de <=> / <=>. Tener muy poco espacio definitivamente es un peligro. La razón más destacada en la que puedo pensar es tener & # 8212 extra; en lugar de estar en & # 8212; es que si se cambia la versión de la biblioteca en tiempo de ejecución necesitará más espacio en jmp_buf, al tener espacio adicional ya reservado, no es necesario volver a compilar programas que se refieran a él.