harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Building DRLVM and classlib on x86_64 platform
Date Wed, 10 May 2006 20:31:31 GMT

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 


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 
[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.

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


Gregory Shimansky, Intel Middleware Products Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message