From owner-freebsd-hackers  Sun Nov 19 00:43:08 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id AAA19181
          for hackers-outgoing; Sun, 19 Nov 1995 00:43:08 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA19176
          for <hackers@FreeBSD.org>; Sun, 19 Nov 1995 00:41:44 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA28132; Sun, 19 Nov 1995 19:35:21 +1100
Date: Sun, 19 Nov 1995 19:35:21 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511190835.TAA28132@godzilla.zeta.org.au>
To: bde@zeta.org.au, cimaxp1!jb@werple.net.au
Subject: Re: int type in jmpbuf
Cc: hackers@FreeBSD.org, jb@cimlogic.com.au
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

>> typedef struct {
>> 	__type_whose_alignment_requirement_i_maximal_t _jb0;
>> 	char _jb1[_NOT_QUITE_THE_FULL_SIZEOF_JMP_BUF];
>> } jmp_buf[1];

>I don't understand the significance of the type (__type_whose..imal_t) for
>_jb0 vs char for _jb1. How is this different to

>typedef struct {
> 	char _jb0[_THE_FULL_SIZEOF_JMP_BUF];
>} jmp_buf[1];

The latter is only guaranteed to be aligned on 1-byte boundaries.

>And if the whole struct should be declared in a machine dependent file, what
>would prevent us from defining the structure from what it contains

>typedef struct {
> 	long reg_edx;
> 	long reg_ebx;
> 	long reg_esp;
>	:
>	:
>} jmp_buf[1];

>I guess the answer to this is that it is supposed to be opaque, but in my
>case I have to manually setup a jmp_buf for each user-space thread and I'd
>like a clean way of accessing the structure. Any ideas?

It's supposed to be opaque to stop that :-).  You should copy setjmp.S
and adapt it.  Note that it isn't possible to do preemptive context
switching for threads using only setjmp() - setjmp() doesn't preserve
all of the floating point state in FreeBSD.

Bruce