Okay, I will file a JIRA as soon as I have a complete solution.
A side question: do we have a philosophical justification
why we as a project prefer to work through JIRA instead of e-mail?
I personally believe that the instruction will not get any clearer
if it is written in JIRA rather than in e-mail, and also tend to think
that noone will ever want to know why build on a particular platform
was failing at some particular point of time in the past.
Accordingly, I think that transient issues like build failures
are better served with e-mailed patches.
Geir Magnusson Jr. wrote:
> Can you open a JIRA with this, explaining what needs to be done, and
> linking the other JIRAs as needed?
>
> Thx
>
> geir
>
> Salikh Zakirov wrote:
>> The patch turned out to be exact duplicate of HARMONY-1571.
>> Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
>>
>> The following change is needed on top of already committed HARMONY-1551
>> to make DRLVM start on Linux/x86_64.
>>
>> However, it still doesn't work properly, failing with
>> java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
>> Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion
>> `!(vt() & 1)' failed.
>>
>> --- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
>> +++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
>> @@ -68,9 +68,9 @@ static void convertOperand2Opnd(
>> }
>>
>> #ifdef _IPF_
>> -static const char* get_reg_value(
>> +const char* InstructionDisassembler::get_reg_value(
>> InstructionDisassembler::Register reg,
>> - const Registers* pcontext)
>> + const Registers* pcontext) const
>> {
>> assert(0);
>> return NULL;
>> @@ -78,9 +78,9 @@ static const char* get_reg_value(
>>
>> #elif defined _EM64T_
>>
>> -static const char* get_reg_value(
>> +const char* InstructionDisassembler::get_reg_value(
>> InstructionDisassembler::Register reg,
>> - const Registers* pcontext)
>> + const Registers* pcontext) const
>> {
>> assert(0);
>> return NULL;
>>
>> Salikh Zakirov wrote:
>>> Hi gang,
>>>
>>> the below patch fixes the problem that prevents DRLVM from being
>>> compilable
>>> on Linux/x86_64.
>>>
>>> The TI itself does not work on x86_64, and the modification only fixes
>>> compiler error.
>>>
>>> diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> b/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> index d29ef32..b4180f6 100644
>>> --- a/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> +++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> @@ -502,7 +502,7 @@ #endif
>>>
>>> const InstructionDisassembler::Opnd& stub_op =
>>> stub_disasm.get_opnd(0);
>>> assert(stub_op.kind == InstructionDisassembler::Kind_Imm);
>>> - method = (Method *)stub_op.imm;
>>> + method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
>>> }
>>> }
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
