Hi Gregory,
1. Many shared libraries in classlib are built without -fPIC option. As far as
Thanks for noting this! Looks like fPIC is just missed in several places.
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
Yes, there are some other places which would have to be slightly corrected to make this buildable on x86_64. But, may be it makes sense to ensure that everybody can build & run it successfully on the supported (e.g. IA32) configuration first? My only concern is that, trying to enhance the DRLVM or it's building system right now by attaching the numerous patches to the original zip archive before it is actually accepted to SVN may cause some extra confusion around it (unless, of course, it will help the people to build and evaluate it on the "supported" config set). But, may be I'm wrong and people on the mailing list think differently.
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.
Ant build for DRLVM just copied the compiler switches from the makefiles which were originally used for building the class libraries (was defined in native-src\linux.IA32\makefile.include). I'm assuming Tim could provide much better answer on that... :)
3. File vm/vmcore/src/thread/hythr/hythreads.h defines type hythread_entrypoint_t like this:
...
which converts int returned by entrypoint to a void* which producess a gcc warning
The returned value by entrypoint isn't used anyways so the correctness of conversion here doesn't matter. Though I agree it looks ugly and we may need to find a more graceful way to resolve this conversion and avoid warning.
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.
With some grepping, I didn't find where these functions are used across the class libraries. As an initial step, trivial commenting out their bodies (or ifdefing) can actually help. With that and some more minor changes (mostly related to the compiler warnings) it should be possible to build and run DRLVM and class libraries on x86_64 (not sure about x86_66 :)). However, I agree with you that it will be nice to have a "fair" implementation of hysignal at least for x86_64. Thanks, Andrey. On 5/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
