harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: Building DRLVM and classlib on x86_64 platform
Date Thu, 11 May 2006 18:55:10 GMT
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 <gshimansky@gmail.com> 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/%3C6928c5160512280441p5a3649a8p7afca5f42ca34161@mail.gmail.com%3E
> >
> > --
> > 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
>
> ---------------------------------------------------------------------
> 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

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


Mime
View raw message