Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jan 2006 07:40:38 +0100
From:      Pav Lucistnik <pav@FreeBSD.org>
To:        Marius Strobl <marius@alchemy.franken.de>
Cc:        freebsd-sparc64@FreeBSD.org
Subject:   Re: need help with ruby-1.8.4
Message-ID:  <1137566438.27313.3.camel@localhost>
In-Reply-To: <20060118023415.I22391@newtrinity.zeist.de>
References:  <1137377234.19156.58.camel@localhost> <20060117005423.A17774@newtrinity.zeist.de> <1137487713.38904.8.camel@pav.hide.vol.cz> <20060118023415.I22391@newtrinity.zeist.de>

next in thread | previous in thread | raw e-mail | index | archive | help

--=-AL33StHLoE6KbQ63zeAp
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Marius Strobl p=ED=A8e v st 18. 01. 2006 v 02:34 +0100:
> On Tue, Jan 17, 2006 at 09:48:33AM +0100, Pav Lucistnik wrote:
> > Marius Strobl p=ED=B9e v =FAt 17. 01. 2006 v 00:54 +0100:
> > > On Mon, Jan 16, 2006 at 03:07:14AM +0100, Pav Lucistnik wrote:
> > > > Hi,
> > > >=20
> > > > Kris Kennaway hurled this error log on me:
> > > >=20
> > > > http://pointyhat.freebsd.org/errorlogs/sparc64-errorlogs/e.5.200504=
2909/ruby-1.8.4_1,1.log
> > > >=20
> > > > And I honestly have no clue how to fix it. Any ideas?
> > > >=20
> > > > Also, is there a working scratchbox for the committers running spar=
c64?
> > >=20
> > > 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.
> >=20
> > First, thank you for your investigation.
> >=20
> > With this patch, I can no longer compile ruby on my amd64, it dies
> > rather mysteriously with
> >=20
> > ./ext/extmk.rb:23:in `require': no such file to load -- rbconfig (LoadE=
rror)
> >         from ./ext/extmk.rb:23
> > *** Error code 1
> >=20
> > Can you check on that arch too?
> >=20
>=20
> Sorry, I fail to understand what's going on on amd64, especially
> since defining FUNCTION_CALL_MAY_RETURN_TWICE to 0 also causes
> strange errors from the interpreter on amd64 but that's exactly
> what ruby-current does. So this might be an unrelated problem
> probably fixed elsewhere in ruby-current and just exposed when
> moving FUNCTION_CALL_MAY_RETURN_TWICE after getcontext(). Keeping
> FUNCTION_CALL_MAY_RETURN_TWICE before getcontext(), i.e. in the
> whole wrapping getcontext() in FUNCTION_CALL_MAY_RETURN_TWICE
> in ruby_setjmp() so it also solves the GCC bug on sparc64, seems
> to work as a workaround but I don't know why.

Do I understand correctly this as having FUNCTION_CALL_MAY_RETURN_TWICE
both just before and just after getcontent() ?

> Did you contact "akr"?

Not yet, I want to have a fully working patch on my hands first.

--=20
Pav Lucistnik <pav@oook.cz>
              <pav@FreeBSD.org>

I cannot be responsible for future messages as apparently my cats have
learned to type.

--=-AL33StHLoE6KbQ63zeAp
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?=
	=?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?=
	=?ISO-8859-1?Q?_zpr=E1vy?=

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQBDzeLmntdYP8FOsoIRAqn3AJ4uarLVFWb6Qlf7CUE58myiSZnmxQCfePRT
cBJyFaN8vnUEc2bfr+5gumY=
=HgxI
-----END PGP SIGNATURE-----

--=-AL33StHLoE6KbQ63zeAp--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1137566438.27313.3.camel>