You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Gregory Shimansky <gs...@gmail.com> on 2006/05/10 22:31:31 UTC
Building DRLVM and classlib on x86_64 platform
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/%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
Re: Building DRLVM and classlib on x86_64 platform
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Gregory Shimansky 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.
>
Can't this be based on platform target?
> 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.
Agreed.
geir
---------------------------------------------------------------------
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
Re: Building DRLVM and classlib on x86_64 platform
Posted by Ivan Volosyuk <iv...@gmail.com>.
Gregory,
Interesting investigations. Looks like classlib porting to 64 bit is needed.
Btw, here is another vector for hacking :)
Since the JIT is not ported to em64t yet, but works on ia32, it could
be possible to build 32-bit version of DRLVM using compatibility layer
in linux-x86_64 (gcc -m32). It should give reasonable performance.
--
Ivan
12.05.06, Gregory Shimansky<gs...@gmail.com> написал(а):
> On Thursday 11 May 2006 20:44 Rana Dasgupta wrote:
> > > >>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?
> >
> > I agree. I think that it is premature to start patching the submission
> > for 64 bit, it's just too confusing.
>
> The submission was what, VM? As I've written VM doesn't have inherent
> limitations not to work on x86_64 platforms in interpreter mode. I've just
> actually made Hello World application to run. Running eclipse causes segfault
> so far somewhere in native libraries of classlib, not in VM.
>
> > > Since port library comes only
> > > in IA32 version, the file hysignal.c fails to compile, specifically
> >
> > functions
> >
> > > infoForGPR, infoForControl and infoForModule. ...
> >
> > Architecture/platform specific code is a genuine issue. We will need to
> > fix files like hysignal.c ( and others similar ) when we do the 64 bit
> > port.
>
> At the moment I've changed the function bodies to assert(0 && "unimplemented")
> and these assertions didn't fail so far.
>
> --
> 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
>
>
--
Ivan
Intel Middleware Products Division
Re: Building DRLVM and classlib on x86_64 platform
Posted by Gregory Shimansky <gs...@gmail.com>.
On Thursday 11 May 2006 20:44 Rana Dasgupta wrote:
> > >>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?
>
> I agree. I think that it is premature to start patching the submission
> for 64 bit, it's just too confusing.
The submission was what, VM? As I've written VM doesn't have inherent
limitations not to work on x86_64 platforms in interpreter mode. I've just
actually made Hello World application to run. Running eclipse causes segfault
so far somewhere in native libraries of classlib, not in VM.
> > Since port library comes only
> > in IA32 version, the file hysignal.c fails to compile, specifically
>
> functions
>
> > infoForGPR, infoForControl and infoForModule. ...
>
> Architecture/platform specific code is a genuine issue. We will need to
> fix files like hysignal.c ( and others similar ) when we do the 64 bit
> port.
At the moment I've changed the function bodies to assert(0 && "unimplemented")
and these assertions didn't fail so far.
--
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
Re: Building DRLVM and classlib on x86_64 platform
Posted by Rana Dasgupta <rd...@gmail.com>.
Hi Gregory/Andrey,
On 5/11/06, Andrey Chernyshev <a....@gmail.com> 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?
I agree. I think that it is premature to start patching the submission
for 64 bit, it's just too confusing.
> Since port library comes only
> in IA32 version, the file hysignal.c fails to compile, specifically
functions
> infoForGPR, infoForControl and infoForModule. ...
Architecture/platform specific code is a genuine issue. We will need to
fix files like hysignal.c ( and others similar ) when we do the 64 bit port.
Thanks,
Rana Dasgupta
Intel Middleware Development.
> > ---------------------------------------------------------------------
> > 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
>
>
Re: Building DRLVM and classlib on x86_64 platform
Posted by Geir Magnusson Jr <ge...@pobox.com>.
This is cool to watch :)
Gregory Shimansky wrote:
> 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 <gs...@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
>
---------------------------------------------------------------------
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
Re: Building DRLVM and classlib on x86_64 platform
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <gs...@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
Re: Building DRLVM and classlib on x86_64 platform
Posted by Andrey Chernyshev <a....@gmail.com>.
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 <gs...@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/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/%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