Re: Need help understanding assertion fail.

[Richard Henderson]

On 2/3/20 4:37 PM, Wayne Li wrote:
> Anyway that's the background.  The specific problem I'm having right now is I
> get the following assertion error during some of the setup stuff our OS does
> post boot-up (the OS is also custom-made):
> 
> qemu_programs/qemu/tcg/ppc/tcg-target.inc.c:224: reloc_pc14_val: Assertion
> `disp == (int16_t) disp' failed.

As Peter has already explained this has to do with *generating* ppc output for
the host, and nothing to do with little vs big endian.

There is only one place from which this ought to be reachable: an extremely
large backward branch, explicitly generated within your tcg ops.

Out of range forward branches are handled gracefully, as they generally occur
due to an internal branch to out-of-line code to handle the slow path of a
memory operation.  Generally this will be "fixed" by restarting generation of
the TB with fewer guest instructions.  E.g.


        insn1
          memory op, conditional branch to m1
 i2:
        insn2
        insn3
        insn4
        branch to next tb with insn5
 m1:
        slow path for insn1
        goto i2

can be split into

        insn1
          memory op, conditional branch to m1
  i2:
        insn2
        branch to next tb with insn3
  m1:
        slow path for insn1
        goto i2


However, these forward branches are implicit, part of the expansion of the
INDEX_op_qemu_ld/st tcg opcodes.

Backward branches are are *only* generated by explicit tcg ops, generated by
your target/ code.  Since you should not be generating backward branches
*between* insns, there is no expectation that splitting the TB in half will
have any effect.

I can only suggest that there is some insn for which you are generating inline
code which includes a loop.  This insn should probably be implemented with an
out-of-line helper instead.  But since I have no visibility into the actual
architecture being emulated, I cannot be sure.


r~