Date: Tue, 17 Jan 2006 00:54:23 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Pav Lucistnik <pav@freebsd.org> Cc: freebsd-sparc64@freebsd.org Subject: Re: need help with ruby-1.8.4 Message-ID: <20060117005423.A17774@newtrinity.zeist.de> In-Reply-To: <1137377234.19156.58.camel@localhost>; from pav@freebsd.org on Mon, Jan 16, 2006 at 03:07:14AM %2B0100 References: <1137377234.19156.58.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
--u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 16, 2006 at 03:07:14AM +0100, Pav Lucistnik wrote: > Hi, > > Kris Kennaway hurled this error log on me: > > http://pointyhat.freebsd.org/errorlogs/sparc64-errorlogs/e.5.2005042909/ruby-1.8.4_1,1.log > > And I honestly have no clue how to fix it. Any ideas? > > Also, is there a working scratchbox for the committers running sparc64? If I fix that compile problem miniruby still segfaults while ruby 1.8.4 is built because of exactly the getcontext(3) related GCC bug that is described in eval.c (the generated code assumes that %l2 didn't change after calling getcontext(3) in rb_call0() here). I'd say it's obvious that the workaround implemented in ruby can't work; we don't want to tell GCC to not make assumptions regarding input, output and local registers before calling getcontext(3) but afterwards. In fact when I additionally move FUNCTION_CALL_MAY_RETURN_TWICE after calling getcontext(3) in ruby_setjmp() miniruby no longer segfaults. But then it turned out that the setjmp(3) approach ruby uses on ia64 apparently is also sufficient to keep GCC from making assumptions regarding the registers in question on sparc64. Therefore I'd suggest to remove the inline asm altogether and move FUNCTION_CALL_MAY_RETURN_TWICE after getcontext(3) (see attached patch). I verified that this doesn't break building ruby 1.8.4 on ia64 and that `make test` still succeeds there (and that miniruby segfaults on both architectures if just remove FUNCTION_CALL_MAY_RETURN_TWICE altogether). I'd suggest to check back with the ruby committer "ark" who added this stuff however. Marius -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-eval.c" --- eval.c.orig Tue Dec 20 14:41:47 2005 +++ eval.c Mon Jan 16 23:54:25 2006 @@ -129,32 +129,21 @@ * But it has not the problem because gcc knows setjmp may return twice. * gcc detects setjmp and generates setjmp safe code. * - * So setjmp call before getcontext call makes the code somewhat safe. - * It fix the problem on IA64. + * So a setjmp call after the getcontext call makes the code somewhat safe. + * It fixes the problem on IA64 and SPARC. * It is not required that setjmp is called at run time, since the problem is * register usage. - * - * Since the magic setjmp is not enough for SPARC, - * inline asm is used to prohibit registers in register windows. */ -#if defined (__GNUC__) && (defined(sparc) || defined(__sparc__)) -#define FUNCTION_CALL_MAY_RETURN_TWICE \ - ({ __asm__ volatile ("" : : : \ - "%o0", "%o1", "%o2", "%o3", "%o4", "%o5", "%o7", \ - "%l0", "%l1", "%l2", "%l3", "%l4", "%l5", "%l6", "%l7", \ - "%i0", "%i1", "%i2", "%i3", "%i4", "%i5", "%i7"); }) -#else static jmp_buf function_call_may_return_twice_jmp_buf; int function_call_may_return_twice_false = 0; #define FUNCTION_CALL_MAY_RETURN_TWICE \ (function_call_may_return_twice_false ? \ setjmp(function_call_may_return_twice_jmp_buf) : \ 0) -#endif #define ruby_longjmp(env, val) rb_jump_context(env, val) #define ruby_setjmp(j) ((j)->status = 0, \ - FUNCTION_CALL_MAY_RETURN_TWICE, \ getcontext(&(j)->context), \ + FUNCTION_CALL_MAY_RETURN_TWICE, \ (j)->status) #else typedef jmp_buf rb_jmpbuf_t; --u3/rZRmxL6MmkK24--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060117005423.A17774>