Hello
I know that x86_64 is not supported at the moment (although VM does support
this mode in interpreter only way if ran with -Dvm.use_interpreter=true), so
I tried to do some porting at home where I run gentoo linux [1]. I didn't
succeed in running anything but moved somewhat in building classlib and VM
and want to share some thoughts which might be useful for all linux builds.
1. Many shared libraries in classlib are built without -fPIC option. As far as
I understand this prevents effective sharing of one library between many
processes, and for me linking just didn't work if sources were compiled
without -fPIC. I had to patch the following files to make classlib build on
x86_64:
build/make/components/classlib/pool.xml
build/make/components/vm/hythr.xml
build/make/components/vm/vmi.xml
build/make/targets/build.native.xml
build/make/targets/common_classlib.xml
I can create a JIRA issue with the patch because I think that all classlib
shared libraries should be built with -fPIC. Maybe there are other places
which I missed because my compilation was not finished.
2. The build/make/targets/common_classlib.xml file had -march=pentium3 which
to me doesn't seem to be necessary. I just deleted this option.
3. File vm/vmcore/src/thread/hythr/hythreads.h defines type
hythread_entrypoint_t like this:
typedef int(* hythread_entrypoint_t)(void*);
so this is a pointer to a function which returns int. In the function
hystart_wrapper in file vm/vmcore/src/thread/hythr/hythreads.cpp:243 there is
a line
return (void*) entrypoint(hyargs);
which converts int returned by entrypoint to a void* which producess a gcc
warning
[cc]
/home/gregory/work/Harmony/Harmony-work/vm/vmcore/src/thread/hythr/hythreads.cpp:243:
warning: cast to pointer from integer of different size
I don't know exactly how safe it is to convert int to a void* in this place so
I just removed -Werror from build/make/targets/common_vm.xml but I think that
int should not be used in places where it may be treated as a pointer. Quite
possibly that code may cause a crash.
4. At this moment I've got VM built (JIT is not built on this platform so I
didn't even have to apply patches from HARMONY-443) but in deploy directory
there were very few API libraries which failed to be preloaded by VM. I've
added em64t architecture to build/make/deploy.xml for vmi and hy* libraries.
That's where compilation didn't work any more. Since port library comes only
in IA32 version, the file hysignal.c fails to compile, specifically functions
infoForGPR, infoForControl and infoForModule. And finally at this point I
found that a question that I was going to ask about x86_64 version of
hysignal.c was asked on Harmony already at [2]. I'll have to look
specifically how the aforementioned functions are used to try to do the port
to x86_66 but probably not tonight.
[1]
My configuration is
kernel: 2.6.15-gentoo-r1
gcc: gcc (GCC) 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)
binutils: 2.16.1
glibc: GNU C Library stable release version 2.3.5
[2]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200512.mbox/[EMAIL
PROTECTED]
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
