Displaying 20 results from an estimated 1000 matches similar to: "[PATCH] fix ARM longjmp with zero 'val'."
2012 Oct 03
0
[klibc:master] [PATCH] fix ARM longjmp with zero 'val'.
Commit-ID: f05ff116bb9edbbb81d82fa47b78e630ce878470
Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=f05ff116bb9edbbb81d82fa47b78e630ce878470
Author: Bill Pringlemeir <bpringle at sympatico.ca>
AuthorDate: Tue, 2 Oct 2012 13:29:52 -0400
Committer: maximilian attems <max at stro.at>
CommitDate: Wed, 3 Oct 2012 18:41:43 +0200
[klibc] [PATCH] fix ARM longjmp
2000 Jun 23
4
Compiling with GCC on win32?
Why does the source use `int64_t'. Is this suppose to be built
with GCC? I have Mumit Kahns gcc, version 2.8.1. Do I need a
2.9.5 version to get the `int64_t' type? I have substituted a
typedef of `long long' in os_types.h. This seems to make sense?
The rint() macro also seems to be having some problems. I guess
there are two meanings to __GNUC__ and _WIN32. One is the OS and
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
2011 Feb 16
2
fwd: fix up ARM assembly to use 'bx lr' in place of 'mov pc, lr'.
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
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
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
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
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 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 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",
2016 Nov 03
1
Transform and "Lenses xx and xx could be used to load this file"
Hi David,
We have a general problem using Augeas in libguestfs and I wonder
if you have any advice.
The problem is that we often -- as with yesterday's patch -- add new
config file paths to lenses. Or we want to parse config files which
are not necessarily in the exact paths that Augeas is expecting.
Now it's easy enough to parse such files using an arbitrary lens by
calling
2015 Apr 28
2
[LLVMdev] MCJIT longjmp failure on Win64 - was Invalid or unaligned stack exception on Windows
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:
>
2011 Apr 27
2
[LLVMdev] built-in longjmp and setjmp
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, again, for historical purposes. Don't use them.
Why is longjmp converted
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
2011 Apr 13
4
[LLVMdev] built-in longjmp and setjmp
On Apr 12, 2011, at 3:15 PM, Jim Grosbach wrote:
> If you want an automated method, then using the source code re-writer interfaces in clang is probably a reasonable starting place. Just modifying the source code manually is probably easier, though, to be honest.
>
> As a moderate caveat to all of this, there are some bits of code out there that use these builtins that are very tightly
2011 Apr 13
3
[LLVMdev] built-in longjmp and setjmp
On Apr 13, 2011, at 9:51 AM, Akira Hatanaka wrote:
> int
> main (int argc, char** argv)
> {
> int n = atoi(argv[1]), r;
>
> if ((r = setjmp (buf)))
> {
> printf("n = %d\n", n);
> return 0;
> }
Non-volatile local variables are not preserved by setjmp(), so this program can print whatever it wants.
/jakob
2005 Apr 20
1
[LLVMdev] setjmp, longjmp and unwind
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,
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 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