mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-12-11 13:56:30 +00:00
3fcb714758
In sandbox, longjmp returns to itself in an endless loop because os_longjmp() calls into longjmp() which is provided by U-Boot which again calls os_longjmp(). Setjmp on the other hand must not return because otherwise the return freees up stack elements that we need during longjmp(). The only straight forward fix that doesn't involve nasty hacks I could find is to directly link against the system setjmp/longjmp implementations. That means we just provide the compiler with hints that the symbol will be available and actually fill them out with versions from libc. This approach should be reasonably platform agnostic Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
35 lines
773 B
C
35 lines
773 B
C
/* SPDX-License-Identifier: GPL-2.0+ */
|
|
/*
|
|
* (C) 2018 Google, Inc
|
|
* Written by Simon Glass <sjg@chromium.org>
|
|
*/
|
|
|
|
#ifndef _SETJMP_H_
|
|
#define _SETJMP_H_
|
|
|
|
struct jmp_buf_data {
|
|
/*
|
|
* We're not sure how long this should be:
|
|
*
|
|
* amd64: 200 bytes
|
|
* arm64: 392 bytes
|
|
* armhf: 392 bytes
|
|
*
|
|
* So allow space for all of those, plus some extra.
|
|
* We don't need to worry about 16-byte alignment, since this does not
|
|
* run on Windows.
|
|
*/
|
|
ulong data[128];
|
|
};
|
|
|
|
typedef struct jmp_buf_data jmp_buf[1];
|
|
|
|
/*
|
|
* We have to directly link with the system versions of
|
|
* setjmp/longjmp, because setjmp must not return as otherwise
|
|
* the stack may become invalid.
|
|
*/
|
|
int setjmp(jmp_buf jmp);
|
|
__noreturn void longjmp(jmp_buf jmp, int ret);
|
|
|
|
#endif /* _SETJMP_H_ */
|