search for: jmp_buf

I am looking through the source and Support/ErrorHandling.cpp/.h says, in so many words, "don't throw exceptions from inside an installed fatal error handling routine". So how are people handling errors during JIT? For command-line compilers, calling exit() or abort() isn't as big a deal -- the compiler is probably going to exit anyway. But say, for instance, the host

Full_Name: Jens Nieschulze Version: R-1.1.1 OS: sparc sun solaris 2.7 Submission from: (NULL) (134.76.192.150) I tried to install R today and got the following at the first try rbitmap.c:239: parse error before `jmp_buf' rbitmap.c:239: warning: no semicolon at end of struct or union rbitmap.c: In function `my_error_exit': rbitmap.c:257: dereferencing pointer to incomplete type rbitmap.c: In function `R_SaveAsJpeg': rbitmap.c:279: storage size of `jerr' isn't known after changing the source cod...

...9vmpoEGI2chUq3GFGIW4z2ql0ywQ%3D&reserved=0 > > The package automatically builds against the gnu-efi version that's > available in Debian at build time. At the moment that's 3.0.9 and the > version Carl uses is linked against that. I suspect this part is wrong: -static jmp_buf load_error_buf; +static jmp_buf *load_error_buf; That will just define a ptr and using that directly in longjmp/setjmp is odd. Modifying longjmp/setjmp to. -longjmp(load_error_buf,1); +longjmp(&load_error_buf,1); makes much more sense to me. Jocke

Full_Name: Albrecht Gebhardt Version: 1.1.1 OS: i86pc Solaris 2.7 Submission from: (NULL) (143.205.61.82) jmp_buf type undeclared, may be related to the installed version of libjpeg (this is v6b), compiler is gcc/g77 2.95.2: root@pc05-stat[X11]# make creating src/unix/X11/Makefile making rbitmap.d from rbitmap.c make[1]: Entering directory `/usr/share/src/R-1.1.1/src/unix/X11' gcc -I. -I../../../src/inclu...

...ards. 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 "Abort trap" under LLVM: #include <setjmp.h> long (*g_pfunc) (); jmp_buf g_jbuf; long foo() { printf("Hello World!\n"); longjmp(g_jbuf, 0); return 0; } main () { g_pfunc = foo; setjmp(g_jbuf); g_pfunc(); } I'm using Mac OS X version 10.3.8 I just installed and build LLVM yesterday from CVS.

...rt_main (main=0x402ac0 <main>, argc=2, ubp_av=0x7ffc53ee5688, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7ffc53ee5678) at libc-start.c:226 result = <value optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 5496455093114277129, 4204960, 140721716614784, 0, 0, -5494405746439844599, -5477823887334535927}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x404f70, 0x7ffc53ee5688}, data = { prev = 0x0, cleanup = 0x0, canceltype = 4214640}}} not_first_call = <v...

...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 saving and clobbering registers is not enough to guarantee correctness of the compiled program. #include <stdio.h> #include <stdlib.h> #include <setjmp.h> jmp_buf buf; void __attribute__((noinline)) sub2 (void) { longjmp (buf, 1); } int main (int argc, char** argv) { int n = atoi(argv[1]), r; if ((r = setjmp (buf))) { printf("n = %d\n", n); return 0; } n += 13; sub2 (); return n; } On Tue, Apr 12, 2011 at...

...9 deletions(-) diff --git a/com32/elflink/ldlinux/execute.c b/com32/elflink/ldlinux/execute.c index 653c880..3955571 100644 --- a/com32/elflink/ldlinux/execute.c +++ b/com32/elflink/ldlinux/execute.c @@ -44,6 +44,7 @@ const struct image_types image_boot_types[] = { { NULL, 0 }, }; +extern jmp_buf __return_to_command_prompt; extern int create_args_and_load(char *); __export void execute(const char *cmdline, uint32_t type, bool sysappend) @@ -136,7 +137,8 @@ __export void execute(const char *cmdline, uint32_t type, bool sysappend) /* Restore the console */ ldlinux_console_init();...

Signed-off-by: Beno?t Allard <benoit.allard at greenbone.net> --- efi/fio.h | 9 --------- 1 file changed, 9 deletions(-) diff --git a/efi/fio.h b/efi/fio.h index 65fff8d..a1bfe68 100644 --- a/efi/fio.h +++ b/efi/fio.h @@ -11,15 +11,6 @@ #define MAX_EFI_ARGS 64 #define WS(c16) (c16 == L' ' || c16 == CHAR_TAB) -/* VPrint is not in export declarations in gnu-efi lib yet

Steve Capper dixit: >> Do we need the fpregs saved even though klibc doesn't do fp? >For gcc targetting Aarch64, We can only guarantee that d8-d15 are >left alone when -mgeneral-regs-only is supplied for building klibc >and any software linked against klibc. I would much prefer to We can enforce this in klcc, just like -mregparm=3 is used by the i386 target. bye, //mirabilos

...rap" 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 "Abort trap" under LLVM: > > #include <setjmp.h> > > long (*g_pfunc) (); > jmp_buf g_jbuf; > > long foo() { > printf("Hello World!\n"); > longjmp(g_jbuf, 0); > return 0; > } > > main () { > g_pfunc = foo; > > setjmp(g_jbuf); > g_pfunc(); > } > > I'm using Mac OS X version 10.3.8 > I just installed and...

Full_Name: Markus Loecher Version: 1.1.1 OS: Solaris Submission from: (NULL) (129.73.1.1) When trying to install R on a Sun SPARC, make fails in the very end, here is the error message: rbitmap.c:239: parse error before `jmp_buf' rbitmap.c:239: warning: no semicolon at end of struct or union rbitmap.c: In function `my_error_exit': rbitmap.c:257: dereferencing pointer to incomplete type rbitmap.c: In function `R_SaveAsJpeg': rbitmap.c:279: storage size of `jerr' isn't known Any help ? Thanks, Markus...

On Thu, 2019-02-07 at 20:17 -0800, H. Peter Anvin wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > On 2/7/19 1:53 PM, Joakim Tjernlund wrote: > \>>> > > > > -z muldefs would bloat the libraries unnecessarily, but worse it might

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

...: Entering directory `/root/R-1.1.0/src/unix/X11' gcc -I. -I../../../src/include -I../../../src/include -I../../../src/include/R_ext -I/usr/X11R6/include -I/usr/local/include -DHAVE_CONFIG_H -mieee-fp -D__NO_MATH_INLINES -fPIC -g -O2 -c rbitmap.c -o rbitmap.o rbitmap.c:239: parse error before `jmp_buf' rbitmap.c:239: warning: no semicolon at end of struct or union rbitmap.c: In function `my_error_exit': rbitmap.c:257: dereferencing pointer to incomplete type rbitmap.c: In function `R_SaveAsJpeg': rbitmap.c:279: storage size of `jerr' isn't known make[5]: *** [rbitmap.o] Error...

On Wed, 2018-12-12 at 17:05 -0600, Carl Karsten wrote: > On Wed, Dec 12, 2018 at 4:54 PM Joakim Tjernlund > <Joakim.Tjernlund at infinera.com> wrote: > > On Wed, 2018-12-12 at 16:00 -0600, Carl Karsten via Syslinux wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know

Building syslinux against gnu-efi 3.0.10 currently fails with: syslinux/efi/main.c:33:8: error: unknown type name ?jmp_buf? 33 | static jmp_buf load_error_buf; | ^~~~~~~ syslinux/efi/main.c: In function ?local_boot?: syslinux/efi/main.c:189:5: warning: implicit declaration of function ?longjmp? [-Wimplicit-function-declaration] 189 | longjmp(&load_error_buf, 1); | ^~~~~~~ syslinux/ef...

...ort trap" is. >> >> Anyway, here's an example of a C program that compiles >> and works properly under normal gcc, but that fails with >> an "Abort trap" under LLVM: >> >> #include <setjmp.h> >> >> long (*g_pfunc) (); >> jmp_buf g_jbuf; >> >> long foo() { >> printf("Hello World!\n"); >> longjmp(g_jbuf, 0); >> return 0; >> } >> >> main () { >> g_pfunc = foo; >> >> setjmp(g_jbuf); >> g_pfunc(); >> } >> >> I...

From: Sylvain Gault <sylvain.gault at gmail.com> Hello there, I propose 2 patches that fix two possible stack overflows either when running a COM32 module or when loading a new config file. I didn't find a better way to do this than to use the infamous setjmp/longjmp functions to restore the stack to a previous state. This makes the logic a bit more complex, but the behavior is not

Barry, Would you mind providing the necessary patch for this behavior? Thanks, Greg > -----Original Message----- > From: Barry Rowlingson [mailto:B.Rowlingson@lancaster.ac.uk] > Sent: Monday, November 04, 2002 8:04 AM > To: r-devel@stat.math.ethz.ch > Subject: Re: longjmp - was: seemingly random "nesting of > readline input" > warnings > > > Luke