JMP_BUF 구조의 각 항목은 무엇을 유지합니까?

Question

나는 Ubuntu 9.10 (karmic koala)을 운영하고 있으며, 나는 jmp_buf 단순히 12 개의 int 배열 인 구조. 내가 사용할 때 setjmp, 그리고 a jmp_buf 구조 - 12 개 항목 중 4 개가 저장됩니다. 이 4 개의 항목은 스택 포인터, 프레임 포인터, 프로그램 카운터 및 리턴 주소입니다. 다른 8 개의 항목은 무엇입니까? 그들은 기계에 의존적입니까? 다른 항목은 세그먼트 테이블베이스 레지스터입니까? 스레드/프로세스의 환경을 올바르게 복원하는 데 필요한 것이 무엇입니까? 나는 Man Page, 다른 출처를 살펴 보았지만 어셈블리 코드를 찾을 수 없었습니다. setjmp.

Answer 1

MacOS X 10.6.2에서 헤더 <setjmp.h> 결국 사용됩니다 <i386/setjmp.h>, 그리고 거기에서 그것은 다음과 같이 말합니다.

#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

Linux에서 유사한 요구 사항을 찾을 수 있습니다. jmp_buf 필요한 상태를 저장하기에 충분한 정보가 포함되어 있습니다. 그리고 그것을 사용하기 위해, 당신은 그것이 포함 된 것을 실제로 알 필요가 없습니다. 당신이해야 할 일은 구현자가 정확하게 얻었다는 것을 믿기 만하면됩니다. 구현을 변경하려면 물론 구현을 이해해야합니다.

setjmp 및 longjmp는 매우 기계적으로 다릅니다. Plauger의 읽기 "표준 C 라이브러리"구현과 관련된 문제 중 일부에 대한 논의를 위해. 더 현대적인 칩은 실제로 구현하기가 더 어려워집니다.

Answer 2

setjmp/longjmp/sigsetjmp CPU 아키텍처, 운영 체제 및 스레딩 모델에 크게 의존합니다. 처음 두 가지 기능이 유명하게 (또는 악명 높게 - POV에 드러냅니다) 원래 UNIX 커널에 I/O 오류 또는 기타 불쾌한 상황에서와 같이 실패한 시스템 호출에서 풀리는 "구조화 된"방법으로 나타났습니다.

/usr/include/setjmp.h (Linux Fedora)의 구조의 의견 호출 환경, 그리고 아마도 저장된 신호 마스크. 여기에는 /usr/include/bits/setjmp.h가 jmp_buf를 선언하여 x86 패밀리에 특정한 6 개의 32 비트 int 배열을 갖도록 선언합니다.

나는 다른 소스를 찾을 수 없지만 PPC 구현, 의견은 FPU 설정이 저장되어야한다는 것을 합리적으로 암시합니다. 반올림 모드, 기본 피연산자 크기, 예외 취급 등을 복원하지 못하기 때문에 합리적입니다.

시스템 엔지니어는 이러한 구조에서 실제로 필요한 것보다 약간 더 많은 공간을 예약하는 것이 일반적입니다. 몇 가지 여분의 바이트는 땀을 흘릴 것이 거의 없습니다. 특히 실제 사용의 희귀 성을 고려합니다. setjmp/longjmp. 공간이 너무 적은 것은 분명히 위험입니다. 내가 생각할 수있는 가장 두드러진 이유는 추가로 발견되는 것과는 달리 런타임 라이브러리 버전이 JMP_BUF에 더 많은 공간이 필요하도록 변경되면 추가 공간을 이미 예약하여 추가 공간을 예약하여 언급 한 프로그램을 다시 컴파일 할 필요가 없기 때문입니다. 그것.