It now builds and links, but fails at runtime because
register_libcore_icu_ICU can't find the file it wants. We'll probably need to replace register_libcore_icu_ICU with a better-behaved version.
Stuff compiles, but linking breaks spectacularly. Next step is to
figure out how to build the dependencies without checking out and
building the entire Android platform.
To execute tests on a remote host (for instance, because you're cross-compiling),
simply do:
make remote-test=true remote-test-host=<host_to_test_on> test
You can set several variables to control the functionality of remote-test.
See them below, along with their default values:
remote-test-host = localhost # host to ssh to
remote-test-port = 22
remote-test-user = ${USER} # user to execute tests as
remote-test-dir = /tmp/avian-test-${USER} # dir to rsync build output to
The primary motivation behind this is to allow all the different Assemblers
to be built at once, on a single machine. This should dramatically reduce
the time required to make sure that a particular change doesn't break
the build for one of the not-so-common architectures (arm, powerpc)
Simply pass "codegen-targets=all" to make to compile all
src/codegen/<arch>/assembler.cpp.
Note that while these architectures are built, they will not be fully-
functional. Certain stuff is assumed to be the same across the entire
build (such as TargetBytesPerWord), but this isn't the case anymore.
Hi
If libjvm.so is in the same directory as avian-dynamic, then there's
no need for LD_LIBRARY_PATH to include that directory, we can just set
the rpath in avian-dynamic to $ORIGIN when linking it. Working patch
attached.
Regards
Damjan
This way, the clean target continues to do what it always did: delete
the whole build directory. You can use clean-current to just delete
the currently-configured build directory.
We need to extract the OpenJDK classes into the build classpath
directory for the target platform before running the
bootimage-generator, or else it won't be able to find the classes.
This package name must match the URL protocol we use for loading
embedded resources, but OpenJDK's URL class won't tolerate underscores
in a protocol name. Also, I had not updated the names of the native
methods in avian.avianvmresource.Handler, leading to
UnsatisfiedLinkErrors when they were called.
set java.vm.version based on makefile version=
in order to display relevant OpenJDK -version information.
Signed-off-by: Matthias Klose <doko@ubuntu.com>
Signed-off-by: Xerxes Rånby <xerxes@zafena.se>
Linux, FreeBSD, and QNX all use ELF, so no need to distinguish between
them when generating object files. To avoid confusion, I've switch
from using operating system names to using binary format names where
applicable.
All but one test is passing. The failure is due to the fact that QNX
doesn't (in general) support calling fork(2) from a multithreaded
process. Thus, we'll need to use spawn instead of fork/exec on QNX,
which I'll attempt in a later commit.
http://www.qnx.com/developers/docs/6.4.1/neutrino/getting_started/s1_procs.html
A multilib-capable x86_64-w64-mingw32 compiler should work just fine,
but since we don't know if it's mutilib or not, we try the
i686-w64-mingw32 version first.
Using e.g. x86_64-w64-mingw32-gcc -m32 doesn't quite work at link time
when using Debian Wheezy's gcc-mingw-w64 package, due to the 32-bit
system libraries not being in the search path, so we use
i686-w64-mingw32-gcc instead.
We were not properly converting dots to slashes internally for package names
and we did not properly handle Method.getAnnotations and
Method.getAnnotation(Class<T>) on methods without any annotations.
Added some tests to cover these cases.
The usage statement for the bootimage-generator now looks like this:
build/linux-x86_64-bootimage/bootimage-generator \
-cp <classpath> \
-bootimage <bootimage file> \
-codeimage <codeimage file> \
[-entry <class name>[.<method name>[<method spec>]]] \
[-bootimage-symbols <start symbol name>:<end symbol name>] \
[-codeimage-symbols <start symbol name>:<end symbol name>]
When link time optimization is enabled, we need to remind the compiler
that we're targeting i586 when linking so it can resolve atomic
operations like __sync_bool_compare_and_swap.
When link time optimization is enabled, we need to remind the compiler
that we're targeting i586 when linking so it can resolve atomic
operations like __sync_bool_compare_and_swap.
The JRE lib dir for OpenJDK 7 on OS X seems to be just "lib", not
e.g. "lib/amd64" by default, so we use that now. Also, the default
library compatibility version for libjvm.dylib is 0.0.0, but OpenJDK
wants 1.0.0, so we set it explicitly.
We never define atomicCompareAndSwap64 for ARM or PowerPC, and
apparently only very recent ARM chips support it, so we must fall back
to synchronization-based emulation.
On Ubuntu 11.10, the optimized build was breaking, apparently because
it was eliminating most of the symbols defined in assembly code
(e.g. vmJump) as unreachable when linking libjvm.so, which left
avian-dynamic unlinkable due to an unresolved symbol.
The solution in this commit is to export makeSystem and makeFinder
from libjvm.so rather than build redundant versions of finder.cpp and
posix.cpp/windows.cpp into avian-dynamic like we've been doing. This
avoids the whole problem of vmJump reachability and reduces the size
of avian-dynamic at the same time.
This commit also turns off LTO for the avian-dynamic link since we get
odd undefined symbol errors about libc-defined symbols otherwise.
This may merit future investigation, but avian-dynamic is so small and
simple that there's no need to optimize it anyway.
This avoids the requirement of putting the code image in a
section/segment which is both writable and executable, which is good
for security and avoids trouble with systems like iOS which disallow
such things.
The implementation relies on relative addressing such that the offset
of the desired address is fixed as a compile-time constant relative to
the start of the memory area of interest (e.g. the code image, heap
image, or thunk table). At runtime, the base pointer to the memory
area is retrieved from the thread structure and added to the offset to
compute the final address. Using the thread pointer allows us to
generate read-only, position-independent code while avoiding the use
of IP-relative addressing, which is not available on all
architectures.
