From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Fri, 22 Jun 2018 13:54:45 +0200 Subject: [U-Boot] [PATCH v4 15/21] sandbox: Fix setjmp/longjmp In-Reply-To: References: <20180618152315.34233-1-agraf@suse.de> <20180618152315.34233-16-agraf@suse.de> <5c1da7a0-8ae5-d1e3-cc89-9342a159a4dc@suse.de> Message-ID: <34f99c82-4205-e0bc-7e51-6479db62f65f@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 06/21/2018 09:45 PM, Simon Glass wrote: > Hi Alex, > > On 21 June 2018 at 03:41, Alexander Graf wrote: >> On 06/21/2018 04:02 AM, Simon Glass wrote: >>> Hi Alex, >>> >>> On 18 June 2018 at 09:23, Alexander Graf 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 >>>> --- >>>> 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