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~
