similar to: [LLVMdev] Re: 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

Hello, I am trying to compile the R package on a sun. I get the error message rbitmap.c: In function 'my_png_error': rbitmap.c:73: structure has no member named 'jmpbuf' rbitmap.c: In function 'R_SaveAsPng': rbitmap.c:122: structure has no member named 'jmpbuf' make[4]:*** [rbitmap.lo] Error 1 Has anyone encountered this problem? Any solutions? Is there are

Hi When building with GCC 10, gcc is stricter in handling handling of symbol clashes. Fedora, has fixed this with a patch from Dominik Mierzejewski: https://src.fedoraproject.org/rpms/tftp/c/5e2aa55b6802a52ef480d688b3ae4751220f20e0.patch Attaching the corresponding patch for git am. Regards, Salvatore >From 9e7641bf58df9dda3bc51f381f371fa7cbce47af Mon Sep 17 00:00:00 2001 From: Salvatore

Hi When building with GCC 10, gcc is stricter in handling handling of symbol clashes. Fedora, has fixed this with a patch from Dominik Mierzejewski: https://src.fedoraproject.org/rpms/tftp/c/5e2aa55b6802a52ef480d688b3ae4751220f20e0.patch Attaching the corresponding patch for git am. I'm sending the patch which was submitted a while ago to the list. Is there something you wanted to be

Peter, There was a mis-merge in the ia64 patch you put into 0.83. Olaf Hering pointed it out. The patch is attached. Olaf claims that he is still unable to compile for ia64 with is toolchain. He's getting the following error: <olh> libc.so(.got+0x0): multiple definition of `_GLOBAL_OFFSET_TABLE_' <olh> tests/getenvtest.o(.got.plt+0x0): first defined here <olh>

Just a quick report on compiling R 0.62.3 for SunOS 4.1.4 and Solaris 2.6 (both with gcc 2.7.2.something), in hopes that it'll be useful to someone. 4.1.4 - I followed Charles Berry's forward of Ross Ihaka's suggestion about putting fake #defines for gamma and lgamma in src/include/Mathlib.h (this works best on the second pass, after the graphics library (which also contains

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(-)

Thanks to the hard work of Bill Wendling (wendling at isanbard.org), LLVM now translates setjmp/longjmp calls into the LLVM "exception handling" instructions invoke & unwind. This means that all of the LLVM optimizers are now aware of the extra control flow edges made possible by setjmp & longjmp, so data flow analyses won't make incorrect transformations. A variety of

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

ARM/Darwin implements them. I'm not aware of any others. That said, they are designed for internal use by the compiler for exception handling. Calling them directly like this is very much not recommended. Using the system library setjmp()/longjmp() functions is preferred. -Jim On Apr 12, 2011, at 1:56 PM, Akira Hatanaka wrote: > Does the X86 backend (or any other backend) correctly

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

On Oct 4, 2011, at 8:23 PM, Khaled ElWazeer wrote: > Actually my problem is solved when I added "__sigsetjmp" to this list. Rafael just added a returns_twice function attribute to LLVM IR. I expect he will update the callsFunctionThatReturnsTwice() function soon. /jakob

Dear list, I want to add SJLJ exception handling to my frontend. Unfortunately, there doesn't seem to be any examples in the documentation as to how to use the intrinsics @llvm.eh.sjlj.setjmp @llvm.eh.sjlj.longjmp @llvm.eh.sjlj.lsda @llvm.eh.sjlj.callsite Is there a way to force Clang to use SJLJ exception handling for C++? That way I would be able to look at its output to learn how to use

I strongly advise you not to use SjLj exception handling. Use zero-cost-exceptions via DWARF instead. If you really want to pursue sjlj anyway, look at the ARM backend. It uses them for darwin targets. -Jim On Jul 12, 2013, at 9:09 AM, Nicolas Ojeda Bar <N.Ojeda.Bar at dpmms.cam.ac.uk> wrote: > Dear list, > > I want to add SJLJ exception handling to my frontend. Unfortunately,

Jim Grosbach <grosbach at apple.com> writes: > I strongly advise you not to use SjLj exception handling. Use > zero-cost-exceptions via DWARF instead. On Windows, DWARF EH doesn't work when there are stack frames not compiled with DWARF EH support (i.e. OS code that invokes user-provided callbacks, a common practice on Windows.)

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

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

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:

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