harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: Building DRLVM and classlib on x86_64 platform
Date Thu, 11 May 2006 22:42:41 GMT
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 <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
> 

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