[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