On Thursday 11 May 2006 17:31 Andrey Chernyshev wrote: > > 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?
Since the discussion about DRL VM had stopped I assumed that everyone who tried had succeeded in building and running it on IA32 platforms so I decided to try experimenting with something different. I know that VM does not have inherent limitations to work on x86_64 platform in interpreter mode, it is classlib and build system that just aren't capable yet. So I tried to identify what parts should be improved to support this target. > 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. I am not attaching anything until I get some better results than bare VM which cannot find any APIs. I'll keep you informed about the progress. > > 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. Ok thanks for clarification, so that place shouldn't at least cause immidiate problems for me. > > 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. They seem to be used in just one place hysig_info, but hysig_info does seem to be used across the hyport library. I decided to follow your suggestion and just change those function code to assertions that they are not implemented and see what will happen. Right now I even have some bootstrap java code executed, but native library from ICU which are downloaded for build are ia32 binaries which cannot be linked with 64-bit process. I'm compiling 64-bit versions of them at the moment. > 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/hythre > >ads.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.mbo > >x/[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] -- 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]
