An update for anyone interested: I didn't remember seeing the leading
0x10 because the values are correct when retrieved from memory. They get
packed into a structure that gets returned in a single register, so the
0x10 second element ends up in the upper 4 bytes of x0 which is provided
as the firs
Ok, thanks for rooting this out. I could swear that I checked that
address several times and I clearly remember 0x4010ca28, but I don't
remember ever seeing 0x10 ahead of it. I'll dig into it a bit and
hopefully find the root cause in my code.
** Changed in: qemu
Status: New => Invalid
--
It does still crash on current QEMU. The proximate cause of the crash is
that you are trying to read from an address which is way outside RAM:
Trace 0: 0x7f8d50054340 [/400195d8/0x82104000] strcmp
PC=400195d8 X00=00104010ca28 X01=4001ec28
X02=00
I would have thought that TLB considerations would not apply when the
MMU is disabled (RTEMS runs in a completely flat memory space). I'll try
to reproduce on more modern QEMU today. Thanks for taking a look at
this.
--
You received this bug notification because you are a member of qemu-
devel-ml
Writing to SCTLR can cause QEMU to flush its TLB (as an internal
implementation detail), so if adding SCTLR writes is sufficient to cause
the problem to go away, I would be suspicious that your guest code is
missing necessary TLB maintenance instructions.
QEMU 3.1 and 4.1 are quite old -- can you
** Description changed:
When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is
not yet publically available), the test generates a spurious data abort (the
MMU and alignment checks should be disabled according to bits 1, 0 of
SCTLR_EL1). The abort information is as follow
