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

[Simon Glass]

Hi,

On 22 September 2017 at 10:19, Alexander Graf <agraf at 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