[U-Boot] setjmp/longjmp prototype in U-Boot

[U-Boot] setjmp/longjmp prototype in U-Boot

[Dr. Philipp Tomsich]

Simon & Alexander,

It appears our setjmp/longjmp prototypes and implementations are
in non-compliance with current C-standards (I checked against
both C99 and C2011).

U-Boot defines setjmp as:
    int setjmp(struct jmp_buf_data *jmp_buf)

The standard however requires
    int setjmp(jmp_buf env)
and has additional guidance regarding the definition of ‘jmp_buf’:
   "The type declared is jmp_buf which is an array type suitable
    for holding the information needed to restore a calling
    environment."

Note that I just reworked the ARM versions: i.e. here we now are
in compliance. Even with this rework, I need to expose 'struct
jmp_buf_data’ (which should be an implementation detail) as this
is explicitly referenced from EFI code.

If agreeable for the EFI side, I'd like to change the remaining
implementations to also comply with the standard, which is easy
enough on by adding a 'typedef struct jmp_buf_data jmp_buf[1]'.
This would also allow us to have a single 'setjmp.h' that just
includes an arch-specific 'asm/setjmp.h' to retrieve the 'struct
jmp_buf_data' definition.

Note that this will entail changes to the EFI code by replacing
all occurrences where 'struct jmp_buf_data' is used or the
address of a 'struct jmp_buf_data' struct-member is
taken (i.e. all call-sites for setjmp/longjmp).

If this is a showstopper to the EFI implementation, let me know…

Regards,
Philipp.

[U-Boot] setjmp/longjmp prototype in U-Boot

[Alexander Graf]

Hi Philipp,

On 09/21/2017 10:57 AM, Dr. Philipp Tomsich wrote:
> Simon & Alexander,
>
> It appears our setjmp/longjmp prototypes and implementations are
> in non-compliance with current C-standards (I checked against
> both C99 and C2011).
>
> U-Boot defines setjmp as:
>      int setjmp(struct jmp_buf_data *jmp_buf)
>
> The standard however requires
>      int setjmp(jmp_buf env)
> and has additional guidance regarding the definition of ‘jmp_buf’:
>     "The type declared is jmp_buf which is an array type suitable
>      for holding the information needed to restore a calling
>      environment."
>
> Note that I just reworked the ARM versions: i.e. here we now are
> in compliance. Even with this rework, I need to expose 'struct
> jmp_buf_data’ (which should be an implementation detail) as this
> is explicitly referenced from EFI code.
>
> If agreeable for the EFI side, I'd like to change the remaining
> implementations to also comply with the standard, which is easy
> enough on by adding a 'typedef struct jmp_buf_data jmp_buf[1]'.
> This would also allow us to have a single 'setjmp.h' that just
> includes an arch-specific 'asm/setjmp.h' to retrieve the 'struct
> jmp_buf_data' definition.
>
> Note that this will entail changes to the EFI code by replacing
> all occurrences where 'struct jmp_buf_data' is used or the
> address of a 'struct jmp_buf_data' struct-member is
> taken (i.e. all call-sites for setjmp/longjmp).
>
> If this is a showstopper to the EFI implementation, let me know…

I don't see anything going against it OTOH :). Please double check the 
converted result still works though ;). IIRC we keep the jmp_buf data on 
the stack - it'd be nice to keep doing that going forward.


Alex

[U-Boot] setjmp/longjmp prototype in U-Boot

[Simon Glass]

Hi,

On 22 September 2017 at 10:19, Alexander Graf <agraf@suse.de> wrote:
> Hi Philipp,
>
>
> On 09/21/2017 10:57 AM, Dr. Philipp Tomsich wrote:
>>
>> Simon & Alexander,
>>
>> It appears our setjmp/longjmp prototypes and implementations are
>> in non-compliance with current C-standards (I checked against
>> both C99 and C2011).
>>
>> U-Boot defines setjmp as:
>>      int setjmp(struct jmp_buf_data *jmp_buf)
>>
>> The standard however requires
>>      int setjmp(jmp_buf env)
>> and has additional guidance regarding the definition of ‘jmp_buf’:
>>     "The type declared is jmp_buf which is an array type suitable
>>      for holding the information needed to restore a calling
>>      environment."
>>
>> Note that I just reworked the ARM versions: i.e. here we now are
>> in compliance. Even with this rework, I need to expose 'struct
>> jmp_buf_data’ (which should be an implementation detail) as this
>> is explicitly referenced from EFI code.
>>
>> If agreeable for the EFI side, I'd like to change the remaining
>> implementations to also comply with the standard, which is easy
>> enough on by adding a 'typedef struct jmp_buf_data jmp_buf[1]'.
>> This would also allow us to have a single 'setjmp.h' that just
>> includes an arch-specific 'asm/setjmp.h' to retrieve the 'struct
>> jmp_buf_data' definition.
>>
>> Note that this will entail changes to the EFI code by replacing
>> all occurrences where 'struct jmp_buf_data' is used or the
>> address of a 'struct jmp_buf_data' struct-member is
>> taken (i.e. all call-sites for setjmp/longjmp).
>>
>> If this is a showstopper to the EFI implementation, let me know…
>
>
> I don't see anything going against it OTOH :). Please double check the
> converted result still works though ;). IIRC we keep the jmp_buf data on the
> stack - it'd be nice to keep doing that going forward.
>
>
> Alex
>

Yes I agree it makes sense.

Note the weird case of sandbox though. I sent a patch for os_setjmp() recently.

Regards,
Simon