This addresses a recent regression where different versions of
MinGW(-w64) had different opinions about whether to use e.g. %I64d or
%lld to print 64-bit integers on 32-bit platforms.
MinGW defines __STRICT_ANSI__ when -std=c++0x is specified, which we
have to override in order to get e.g. strdup. Also, we need to
specify -D_WIN32_WINNT=0x0500 to get post-Windows-2000 functions like
GetModuleHandleEx. Finally, it seems that GCC 4.8.1 wants us to use
%I64d instead of %lld on Windows.
If AVIAN_AOT_ONLY is defined and the VM is asked to compile a method
anyway, we should abort immediately rather than let it crash later
(e.g. due to an access violation on a non-jailbroken iPhone). This
makes debugging such issues a bit easier since the failure will come
earlier and with a more obvious cause.
If a BuiltinElement is never used (i.e. we never try to load anything
from it), its init method will never be called, and thus its backing
library will never be loaded. In that case, we should not try to call
library->disposeAll() in the destructor.
Lots has changed since we forked Android's libcore, so merging the
latest upstream code has required extensive changes to the
Avian/Android port.
One big change is that we now use Avian's versions of
java.lang.Object, java.lang.Class, java.lang.ClassLoader, some
java.lang.reflect.* classes, etc. instead of the Android versions.
The main reason is that the Android versions have become very
Dex/Dalvik-specific, and since Avian is based on Java class files, not
dex archives, that code doesn't make sense here. This has the side
benefit that we can share more native code with classpath-avian.cpp
and reduce the amount of Java/C++ code duplication.
This function allows you to call native code such that any
SIGSEGV/SIGBUS/SIGFPE/EXC_ACCESS_VIOLATION/etc. raised by that code is
transformed into a Java exception and thrown by tryNative. Note that
this effectively results in a longjmp out of whatever function raised
the exception, so any C++ destructors or other cleanup code will not
be run.
Recent versions of jni.h such as the one provided by Debian Jessie's
OpenJDK define UNUSED in a way that conflicts with our definition and
usage, so we need to explicitly undefine it before redefining it to
avoid compiler noise.
It looks like the UNIXProcess class has added posix_spawn support,
which is enabled by default unless overriden by the
jdk.lang.Process.launchMechanism system property. For some reason I
haven't bothered to investigate, posix_spawn fails on MacOS, so this
patch sets the aforementioned property to "fork" to get the old,
working behavior.
This particular problem was introduced in the recent "compiler types" refactor.
It's unclear why it wasn't encountered before now.
Note that the full, unproguarded bootimage build is still blocked by #305
So there I was, planning to just fix one little bug: Thread.holdsLock
and Thread.yield were missing for the Android class library. Easy
enough, right? So, I added a test, got it passing, and figured I'd go
ahead and run ci.sh with all three class libraries. Big mistake.
Here's the stuff I found:
* minor inconsistency in README.md about OpenSSL version
* untested, broken Class.getEnclosingMethod (reported by Josh)
* JNI test failed for tails=true Android build
* Runtime.nativeExit missing for Android build
* obsolete assertion in CallEvent broke tails=true Android build
* obsolete superclass field offset padding broke bootimage=true Android build
* runtime annotation parsing broke bootimage=true Android build
(because we couldn't modify Addendum.annotationTable for classes in
the heap image)
* ci.sh tried building with both android=... and openjdk=..., which
the makefile rightfully balked at
Sorry this is all in a single commit; I didn't expect so many
unrelated issues, and I'm too lazy to break them apart.
