harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Etienne Gagnon <egag...@sablevm.org>
Subject Re: [sablevm] SIGSEGV signal received from Cygwin
Date Thu, 06 Apr 2006 15:19:10 GMT
Enrico Migliore wrote:
> I'm doing some testing on SableVM, and noticed that is receives the very
> same segmentation fault signal that JCHEVM does, from
> pthread_key_create() which is embedded in:
> /usr/bin/cygwin1.dll
> I read around that this problem could be fixed, but the error means that
> the Cygwin platform can only be used for developing, studying and
> testing and not for real world use.

Can you expand a little on this.  I am not sure what you mean.

> problem 1:  POSIX dependancy
> ---------------------------------
> The code contains a certain number of POSIX calls (dependancies). Much
> of them can be easily replaced, but some might be hard to replace.

I think that moving to Harmony's port library should solve this.  I
agree that it shouldn't be hard to fix.

> problem 2:  GCC extensions
> -----------------------------
> The code contains some GCC extensions which are not ANSI.

When compiling a switch interpreter (--with-treading=switch), there
shouldn't be GCC extensions.  The only exception is atomic operations
which cannot be expressed in C.  Yet, I've found an elegant solution to
this: use Hans Boehm's atomic_ops library to get this code out of
SableVM.  See:


> problem 3:  Which compiler?
> -----------------------------
> GCC seems to be the best candidate but MSVC is more popular.

Ideally, I'd like both to work.  Getting the faster direct/inlined
interpreters to work with MSVC might be tricky (require inline assembly
or linking to an asm library), but the switch interpreter shouldn't be a

> problem 4:  Native code dependancies
> ---------------------------------------
> The Harmony class library depends on the port layer:
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html

Yep, using this layer and atomic_ops should hopefully be sufficient to
remove all system-specific dependencies.  If anything is missing, we
should probably abstract it into the port layer.

Now, the interesting thing would be for Harmony native code to compile
and work on something other than ia32.  SableVM already works on pretty
much anything (using gcc, so far), as long as libffi and GNU classpath
compiles on the target.  The only other limitation is 2 operations that
cannot be expressed in C: compare_and_swap and clear_cache.


Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

View raw message