Hi Alex, On 21 June 2018 at 03:41, Alexander Graf <ag...@suse.de> wrote: > > On 06/21/2018 04:02 AM, Simon Glass wrote: >> >> Hi Alex, >> >> On 18 June 2018 at 09:23, Alexander Graf <ag...@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 <ag...@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. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot