Displaying 20 results from an estimated 7000 matches similar to: "[LLVMdev] llvm-gcc4 and setjmp"
2007 Aug 24
1
[LLVMdev] llvm-gcc4 and setjmp
Hello, Jay.
> the resulting bitcode doesn't use LLVM's exception handling
> intrinsics, it just has a call to a function called "_setjmp". And
> there doesn't seem to be any provision for returning the current value
> of the volatile variable v if setjmp returns non-zero - the bitcode
> always returns zero, whereas the spec for setjmp() says that f()
>
2008 Jul 08
0
[LLVMdev] Intrinsics and it's documentation.
On Mon, Jul 7, 2008 at 6:41 PM, Mahadevan R <mdevan.foobar at gmail.com> wrote:
> On Tue, Jul 8, 2008 at 12:00 AM, Chris Lattner <sabre at nondot.org> wrote:
>> On Mon, 7 Jul 2008, Mahadevan R wrote:
>>> While going through the list of intrinsics in Intrinsics.td, I found
>>> that it does not match the list given in Language Reference [1]. Does
>>>
2007 Aug 28
1
[LLVMdev] llvm-gcc4 and setjmp
Hello, Torvald
> is there documentation about what happens to setjmp() et al, and how one
> should handle the setjmp intrinsics?
You shouldn't use them at all.
> Are setjmp() function calls transformed to intrinsics, or are
> the intrinsics only used for EH?
Intrisincs are used for representing necessary EH code flow. User's
setjmp() are just function calls. We fixed
2009 Feb 26
0
[LLVMdev] Question LowerSetJmp
Hi zhangzw,
> In llvm src the file llvm/lib/Transforms/IPO/LowerSetJmp.cpp, it
> seems for sjlj-eh ?
it's not for sjlj-eh. The problem with setjmp/longjmp is that they
can jump from one part of a function to any other part, which means
that the control-flow graph is pointless; this makes everything more
complicated. So how to deal with this? LLVM does have constructs
that allow
2011 Aug 03
1
[LLVMdev] LowerSetJmp Dead?
This pains me to ask, because I'm the original author of this pass, but is the LowerSetJmp pass dead? I created a simple program, manually converted it to use the @llvm.setjmp/@llvm.longjmp intrinsics, ran "opt -lowersetjmp" on it, and tried to compile it only to get this:
Undefined symbols for architecture x86_64:
"___llvm_sjljeh_throw_longjmp", referenced from:
2008 Jul 08
2
[LLVMdev] Intrinsics and it's documentation.
On Tue, Jul 8, 2008 at 12:00 AM, Chris Lattner <sabre at nondot.org> wrote:
> On Mon, 7 Jul 2008, Mahadevan R wrote:
>> While going through the list of intrinsics in Intrinsics.td, I found
>> that it does not match the list given in Language Reference [1]. Does
>> this mean that they are not to be used / don't work? Or is it just
>> that the documentation is
2007 Aug 24
0
[LLVMdev] llvm-gcc4 and setjmp
Hi,
I'm using LLVM 2.0 on cygwin and x86_64-linux-gnu. If I compile a simple
program using setjmp:
#include <setjmp.h>
extern jmp_buf j;
extern void g(void);
int f(void)
{
volatile int v = 0;
if (setjmp(j))
return v;
v = 1;
g();
return 0;
}
the resulting bitcode doesn't use LLVM's exception handling intrinsics, it
just has a call to a function called
2005 Nov 21
1
[LLVMdev] setjmp/longjmp interoperable between llvm and 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
2013 May 08
1
[LLVMdev] Clarifying the state of setjmp/longjmp support in LLVM and Clang
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
2011 Oct 04
2
[LLVMdev] setjmp - 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
2011 Oct 05
0
[LLVMdev] setjmp - longjmp
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",
2009 Feb 26
2
[LLVMdev] Question LowerSetJmp
Hi
In llvm src the file llvm/lib/Transforms/IPO/LowerSetJmp.cpp, it
seems for sjlj-eh ? but this pass has no effect about c++ sjlj-eh.
this pass is for future extend?
zhangzw
2011 Oct 04
0
[LLVMdev] setjmp - longjmp
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
2011 Oct 04
3
[LLVMdev] setjmp - longjmp
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
2012 Jul 01
2
[klibc:master] arm/setjmp.S: fix longjmp
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
2016 Sep 16
2
setjmp/longjmp and volatile stores, but non-volatile loads
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
2005 Apr 20
2
[LLVMdev] setjmp, longjmp and unwind
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
2011 Apr 13
0
[LLVMdev] built-in longjmp and setjmp
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
2005 Apr 20
0
[LLVMdev] setjmp, longjmp and unwind
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
2016 Dec 18
4
setjmp/longjmp and volatile stores, but non-volatile loads
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