[U-Boot] [PATCH v4 15/21] sandbox: Fix setjmp/longjmp

[Alexander Graf <agraf@suse.de>]

On 06/21/2018 09:45 PM, Simon Glass wrote:
> Hi Alex,
>
> On 21 June 2018 at 03:41, Alexander Graf <agraf@suse.de> wrote:
>> On 06/21/2018 04:02 AM, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On 18 June 2018 at 09:23, Alexander Graf <agraf@suse.de> wrote:
>>>> In sandbox, longjmp returns to itself in an endless loop. Cut this through
>>>> by calling the real OS function.
>>>>
>>>> Setjmp on the other hand must not return. So here we have to call the OS
>>>> setjmp function straight from the code where the setjmp call happens.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>> ---
>>>>    arch/sandbox/cpu/cpu.c            |  5 -----
>>>>    arch/sandbox/cpu/os.c             | 20 ++------------------
>>>>    arch/sandbox/include/asm/setjmp.h |  4 +++-
>>>>    3 files changed, 5 insertions(+), 24 deletions(-)
>>>>
>>> I think we do need to do something like this. But I cannot find the
>>> man page for _longjmp(). Are you sure this is a valid function on all
>>> systems? Or is it Linux only?
>>
>> I'm afraid it may be Linux (glibc) only.
>>
>> I guess the alternative to this would be to not use system setjmp/longjmp at all and instead use the in-U-Boot versions of them.
> So can we update this patch to check for Linux glibc? Failing that,
> perhaps setjmp() could return a negative error value? Then (in other
> patches) the caller can make a note that longjmp() cannot be used, and
> will return errors from things that need to call it.

I actually think there is a much easier way. We can just directly export 
the symbols for libc's setjmp/longjmp functions in the sandbox setjmp.h 
header. That way we avoid all the nasty problems we've encountered so 
far. I've cooked up a patch and it seems to work fine.


Alex