Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <446345D9.5060901@pobox.com>
Date: Thu, 11 May 2006 10:10:33 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: Building DRLVM and classlib on x86_64 platform
References: <200605110031.31171.gshimansky@gmail.com>
In-Reply-To: <200605110031.31171.gshimansky@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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