similar to: LLVM now supports setjmp/longjmp!

On Mon, 21 Nov 2005 16:53:58 -0600 (CST), Chris wrote: >On Mon, 21 Nov 2005, Kurt Harriman wrote: >> I would like to build an x86 executable consisting of a number of >> subsystems (mostly legacy C code). One subsystem will be compiled >> to native code using llvm. It calls, and is called by, the other >> subsystems, many of which have to be compiled using gcc

Hi, I would like to build an x86 executable consisting of a number of subsystems (mostly legacy C code). One subsystem will be compiled to native code using llvm. It calls, and is called by, the other subsystems, many of which have to be compiled using gcc because they use small amounts of inline assembly. All of the subsystems catch and throw errors to one another using setjmp/longjmp. When

Commit-ID: d7d16afbdae9bdea83aeb26ac572e6fc4d7d4940 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=d7d16afbdae9bdea83aeb26ac572e6fc4d7d4940 Author: Steve McIntyre <steve at einval.com> AuthorDate: Fri, 29 Jun 2012 18:13:34 +0100 Committer: maximilian attems <max at stro.at> CommitDate: Sun, 1 Jul 2012 22:51:00 +0200 [klibc] arm/setjmp.S: fix longjmp

From: Matt Fleming <matt.fleming at linux.intel.com> POSIX specifies that if 0 is passed as the 'val' argument to longjmp(), setjmp() must return 1. setjmp() must NOT return 0 if it's returning because of a call to longjmp(). Signed-off-by: Matt Fleming <matt.fleming at linux.intel.com> --- com32/lib/setjmp.S | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)

Actually my problem is solved when I added "__sigsetjmp" to this list. Thanks, -Khaled On Tue, Oct 4, 2011 at 10:27 PM, Khaled ElWazeer <khalid.alwazeer at gmail.com>wrote: > > That code should do it, but I realized you only detect setjmp functions by > name. My code is calling "__sigsetjmp" not "segsetjmp". You only support > these functions:

I'm trying to make sense in the support for setjmp/longjmp in Clang and LLVM, with only partial success. I'll try to summarize my findings in the hope that someone can shed some light on why things are the way they are and what I'm missing. Clang. Clang recognizes two forms of setjmp (all I say here applies to longjmp similarly): * __builtin_setjmp: gets lowered to calling the

On Tue, Oct 4, 2011 at 3:10 PM, Khaled ElWazeer <khalid.alwazeer at gmail.com> wrote: > Hi, > > I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable > is inserted, which is fine. The problem is that in the backend before > calling longjmp, some register was spilled to a stack location which is live > across the jmp. I mean, it will be live after

That code should do it, but I realized you only detect setjmp functions by name. My code is calling "__sigsetjmp" not "segsetjmp". You only support these functions: static const char *ReturnsTwiceFns[] = { "_setjmp", "setjmp", "sigsetjmp", "setjmp_syscall", "savectx", "qsetjmp",

Commit-ID: edf92a18d1f1725896c928cbcf580abc268f307c Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=edf92a18d1f1725896c928cbcf580abc268f307c Author: James Cowgill <james.cowgill at mips.com> AuthorDate: Fri, 2 Mar 2018 08:33:03 -0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Wed, 2 Jan 2019 03:08:04 +0000 [klibc] mips: don't save

On Oct 4, 2011, at 3:53 PM, Eli Friedman wrote: > On Tue, Oct 4, 2011 at 3:10 PM, Khaled ElWazeer > <khalid.alwazeer at gmail.com> wrote: >> Hi, >> >> I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable >> is inserted, which is fine. The problem is that in the backend before >> calling longjmp, some register was spilled to a

Hi, I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable is inserted, which is fine. The problem is that in the backend before calling longjmp, some register was spilled to a stack location which is live across the jmp. I mean, it will be live after jumping. The stack location was initialized before the call to setjmp, and is used afterwards. Is there any bug in handling

On Wed, 20 Apr 2005, Greg Pettyjohn wrote: > I'm trying to get unwind to work. > > I was unable to get an unwind example to work directly, > so I decided to compile a c program that uses setjmp > and longjmp and work backwards. > > I keep running into a "Abort trap" problem, whatever "Abort trap" is. > > Anyway, here's an example of a C

I'm trying to get unwind to work. I was unable to get an unwind example to work directly, so I decided to compile a c program that uses setjmp and longjmp and work backwards. I keep running into a "Abort trap" problem, whatever "Abort trap" is. Anyway, here's an example of a C program that compiles and works properly under normal gcc, but that fails with an

Hi, In our (non-C) compiler we use setjmp/longjmp to implement exception handling. For the initial implementation LLVM backend, I'm keeping that model. In order to ensure that changes performed in a try/setjmp==0 block survive the longjmp, the changes must be done via volatile operations. Given that volatility is a property of individual load/store instructions rather than of memory slots in

On Apr 27, 2011, at 4:08 PM, Joerg Sonnenberger wrote: > On Wed, Apr 27, 2011 at 03:55:53PM -0700, Jim Grosbach wrote: >> The builtins are for internal compiler use in the context of SjLj >> exception handling. Any other use, including any direct calls of the >> builtins in user code, are a bad idea with no guaranteed behaviour. >> That they're exposed at all is,

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

First I try it with bytecodes: ~/compiler/temp$ llvmgcc sjmp01.c -o sjmp01 ~/compiler/temp$ ./sjmp01 Hello World! Abort trap Same results for lli sjmp01.bc Now I try converting to native code: ~/compiler/temp$ llc sjmp01.bc -enable-correct-eh-support -o sjmp01.s ~/compiler/temp$ gcc sjmp01.s -o sjmp01.native ~/compiler/temp$ ./sjmp01.native Hello World! Bus error ~/compiler/temp$ On Apr 20,

Jonas Maebe via llvm-dev wrote: > Then, I tried the following: > a) if the longjmp for the try-block is taken (i.e., the setjmp right > before the try-block returns a non-zero value), jump to the landingpad BBL. > > -> Problem: LLVM does not allow regular jump edges to landingpad BBLs > > b) since the landingpad is empty anyway and falls through into the next > BBL

On 30/09/16 20:10, Reid Kleckner wrote: > On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be > <mailto:jonas-devlists at watlock.be>> wrote: > > So, can I use invoke and landingpad without using any of the other > exception handling intrinsics? (in combination with a dummy personality > function) Or will LLVM in all cases insist on

It seems straightforward to implement, if it just needs to be functionally correct. I have another question about setjmp/longjmp. When the following program is compiled and run with argument 10 (./a.out 10), should it print 10 or 23? I am asking this question because it prints 23 when compiled with gcc and prints 10 when compiled with clang. If it is supposed to return 23, it seems to me that