[PTLsim-devel] Problems with Java

Mon Aug 6 10:59:01 EDT 2007

Hi,

You are right, the virtual machine was not supposed to go to that address
and starts executing whatever was there. After some debugging, I found
that the stack pointer got corrupted after executing a certain code block.
The reason is the way push and pop was implemented in Uop.

In decode-complex.cpp, there is an implementation for push/pop (cases 0xff
and 0x8f respectively). The implementation for push accounts for 32/64
modes while the pop implementation doesn't (all offsets are based on
64bit). This results in pushes changing SP by 4 bytes and pops changing it
by 8 bytes for 32bits applications.
Please let me know if am missing something here.

I did a quick fix, and now JikesRVM executes a little bit longer. However
it still fails. Another outcome is that Sun JDK executes correctly under
userspace ptlsim, but still fails under PTLsim/Xen.

Currently am trying to compare the output from GDB to PTLsim log files.
I'll let you know once I find the cause for JVM failure.

Best regards,
Bashar Gharaibeh

> On Saturday 21 July 2007 20:12, Bashar M. Gharaibeh wrote:
>> Hi,
>>
>> Currently I'm using revision #219
>>
>> PTLsim reports the following in the log file regarding the invalid
>> opcode:
>>
>> translate: invalid opcode at iteration 338980: 0x60 commits 1970234 (at
>> ripstart 0x604b5a2b, rip 0x604b5a2c); may be speculative
>> [vcpu 0] Barrier (#0 -> 0x7001be40 invalid_opcode called from
>> 0x604b5a2b;
>> return to 0x604b5a2c) at 338980 cycles, 1970238 commits
>> Exception 6 (invalid opcode) @ rip 0x604b5a2b (1970238 commits, 338980
>> cycles)
>>
>> the disassembled code is:
>> ...
>>    4B                dec bx
>>
>> >> 60                pusha
>>
>>    46                inc si
>> ..
>
> You're right - we did forget to write the microcode for PUSHA. You can do
> this
> yourself (just add it to decode-complex.cpp following the pattern for PUSH
> and POP in decode-fast.cpp; consult the Intel or AMD manuals for details).
> I'll add it to our to-do list for the next release.
>
> However, I'm surprised the Java JVM is using this instruction, since
> something
> looks suspicious about your disassembly. Are you sure this code is valid,
> and
> you're using the right objdump options? It looks like 16-bit real mode
> code
> (or 64-bit code, which uses the 0x4x opcodes for something entirely
> different), not 32-bit code. This is especially true since PUSHA is not
> generated by any modern compiler.
>
> - Matt
>
> -------------------------------------------------------
>  Matt T. Yourst                    yourst at peptidal.com
>  Peptidal Research Inc., Co-Founder and Lead Architect
> -------------------------------------------------------
>