From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Thu, 21 Jun 2018 11:41:32 +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> Message-ID: <5c1da7a0-8ae5-d1e3-cc89-9342a159a4dc@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 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. Alex