search for: longjmps

On 28 April 2015 at 00:30, Reid Kleckner <rnk at google.com> wrote: > I think Paweł identified the problem. The frames on the stack between the > setjmp and longjmp must have valid unwind information, which is described > here: > https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396 > > In particular, it has this line about JITed code: >

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

...se the optimization was already present for C++ EH, and they use the same underlying mechanisms. For now, setjmp/longjmp support only interacts with C++ exception handling partially correctly. In particular, if there is a "catch block" or destructors which must be run in a function that longjmps, they will not be executed correctly (however, catch blocks and dtors higher up in the stack will). This may be fixed sometime after the 1.0 release, but it is not super high priority. In particular, this testcase works: void jmp() { longjmp(...); } void test() { try { AClass A; // A'...

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

[klibc] [PATCH] fix ARM longjmp with zero 'val'. We need to set the condition codes on the ARM. The previous version was using a left over condition code from the caller. Also, use conditional execution to eliminate branch and reduce size. Signed-off-by: Bill Pringlemeir <bpringle at sympatico.ca> diff --git a/usr/klibc/arch/arm/setjmp.S b/usr/klibc/arch/arm/setjmp.S index

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

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

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

Do the LLVM Setjmp/Longjmp intrinsics interact with C++ exception handling and execute C++ cleanup actions? I compiled a small example using setjmp/longjmp using clang and they did not execute C++ cleanup actions and calling longjmp bypassed calling destructors on objects that were allocated between the call to setjmp and longjmp. I’m wondering if the LLVM intrinsics behave differently from

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

Commit-ID: 87ad992e1ae0036436646610a23feb4c2895593f Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=87ad992e1ae0036436646610a23feb4c2895593f Author: Anton Blanchard <anton at samba.org> AuthorDate: Tue, 3 Dec 2013 18:18:03 +1100 Committer: H. Peter Anvin <hpa at zytor.com> CommitDate: Tue, 3 Dec 2013 10:53:19 -0800 [klibc] ppc64: Add ppc64le support Add

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",

Add PowerPC 64bit little endian support. Signed-off-by: Anton Blanchard <anton at samba.org> --- Makefile | 7 +++++-- usr/klibc/arch/ppc64/MCONFIG | 4 ++-- usr/klibc/arch/ppc64/crt0.S | 34 ++++++++++++++++++++----------- usr/klibc/arch/ppc64/setjmp.S | 40 ++++++++++++++++++++++++++---------- usr/klibc/arch/ppc64/sysstub.ph | 45

hello vorlon, got notified of your patch, will apply next days upstream unless some critiques are voiced on ml. thanks. -- maks ----- Forwarded message from Steve Langasek <steve.langasek at canonical.com> ----- Date: Wed, 16 Feb 2011 22:05:42 -0000 From: Steve Langasek <steve.langasek at canonical.com> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses

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

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

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 Sun, Dec 18, 2016 at 02:23:01PM +0100, Jonas Maebe via llvm-dev wrote: > Recap: we use setjmp/longjmp for our exception handling on all platforms in > our regular (non-LLVM) code generators. I'd like to use the same > infrastructure with the LLVM code generator for code interoperability > purposes (the LLVM SjLj personality is not binary-compatible with our > existing

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: