[aarch64-port-dev ] assertion failure bcp doesn't belong to this method

[Andrew Dinn]

Hi Daniel,

Like Andrew (Haley) I am really excited to hear that you are working on
this project.

On 18/02/14 10:59, D.Sturm wrote:
>>
>> "simpf" gets you the current Java frame.  "nextpf" the next one, etc.
>> So you'll be able to see where it failed.
>>
> That's *very* useful, I read the README file but after seeing simbt (which
> just tells me 0: <unknown method> 0x7fffec0a522c) I didn't look careful
> enough at the other sim commands.

Persevere with them. In particular the different break commands are
really worth understanding (simbreak, simbreakbc and simbreakreloc).
Note that simbreak is used to break an absolute address and will not
allow for relocation of code. It is best for breaking specific addresses
in the template interpreter code. simbreakbc and simbreakreloc are for
breaking, respectively, interpreted and compiled code by symbolic
(method) name (with bytecode index or offset into the compiled code) and
you will almost certainly need to use both to trap some break points you
are interested in because the VM regularly uses a mix of interpreted and
compiled code. That's true even if you specify -Xcomp because methods
frequently get decompiled and revert back to interpreted. If you run
with -Xint then you can just use simbreakbc.

Also, in order for interpreted breakpoints and stack backtrace to work
correctly you need to add -XX:-DisableBCCheck on the java command line.
DisableBCCheck is normally true and this stops the simulator regularly
calling back into the VM at method entry/exit to identify details of the
current method and at bytecode boundaries when interpreting to identify
the current bytecode name and index. Passing -XX:-DisableBCCheck resets
it to false. This will slow down the simulator (adding. maybe, 25-100%
to execution time depending upon how much interpreted Java code you are
running) but it makes simbreakbc and simbt work.

A few extra hints:

  simbreakbc needs to be given an actual bytecode index i.e. if the
bytecode boundaries are at 4 and 6 then a break with bytecode index 5
will never be triggered.

  simbreakreloc usually needs an offset of 12 or 16 because the start of
a compiled method includes the non-verified entry code prolog which is
usually 3-4 instructions. most method calls enter at the verified entry
point which comes just after that prolog.

  use "simcompiled" to list currently known compiled methods

  use "simdis address count" to see the count instructions starting at a
code address. omitting count disassembles one instruction. omitting
address disassembles the instruction at the current simulator PC.

  use "simprint" for a full stack backtrace including as extra data a
dump of FP, SP, PC etc and stack contents. Supplying a count prints
multiple frames.

> Playing around a bit I could create a case that deterministically fails
> with a bcp of 0xbadbad at least, so the problem seems to be that I use a
> thrashed register. Just have to figure out why it works fine for the first
> few compilations and fails then.

0xbadbad is deliberately written into AArch64 registers 0-15 after a
Java -> VM callout returns (although if the VM call returns an integral
type value then r0 will be overwritten with the result). That's to
ensure that Java code cannot rely on a register value just hanging
around across a VM callout. Of course, when running an x86 only build
the x86 call usually trashes all registers by the time it returns. So,
if you are seeing 0xbadbad then the problem is likely to be that the
generated ARM code is treating a volatile register as non-volatile
across a VM callout.

regards,


Andrew Dinn
-----------