harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm][em64t] drlvm broken on em64t?
Date Tue, 12 Dec 2006 22:12:46 GMT
Geir Magnusson Jr. wrote:
> 
> 
> Gregory Shimansky wrote:
>> On Wednesday 13 December 2006 00:26 Geir Magnusson Jr. wrote:
>>> Gregory Shimansky wrote:
>>>> Geir Magnusson Jr. wrote:
>>>>> This must be from the recent properties refactoring...
>>>> I've found out the reason of the change. It is r486100 in classlib.
>>>> Previously there was no call to GetSystemProperty about
>>>> org.apache.harmony.boot.class.path. I've fixed drlvm function
>>>> GetSystemProperty to return VMI_ERROR_NOT_FOUND in case a property
>>>> cannot be found and set valuePtr to NULL (or otherwise luniglob 
>>>> crashes).
>>>>
>>>> This still doesn't work because org.apache.harmony.boot.class.path is
>>>> not set anywhere, and then bootstrap class loader fails to initialize.
>>>> I'm still trying to find out what else had changed.
>>> That property is constructed by luni when the .so is loaded.  If this
>>> doesn't work on em64t, it shouldn't work anywhere...
>>
>> Yes it does not work anywhere. Just update classlib and you will see.
>>
>> Take a look at the diff of r486100. Now if VMI GetSystemProperty 
>> returns that property is not found, the function 
>> readClassPathFromPropertiesFile just returns JNI_ERR and doesn't set 
>> any of the properties read from the bootclasspath.properties file. I 
>> don't think it is right.
> 
> I traced all this machinery a while ago when I first changed how we 
> handled this.  I'm sure it's obvious - I can look in a few min

I've created a patch already and set it to the mail list. If it doesn't 
break IBM VME and you don't have any objections I'll commit it. I'm 
already running drlvm tests and they work again.

-- 
Gregory


Mime
View raw message