On 10/19/21 9:44 AM, Warner Losh wrote:
> + regs->regs[15] = tswap32(gr[TARGET_REG_PC]);
> + cpsr = tswap32(gr[TARGET_REG_CPSR]);
> + cpsr_write(regs, cpsr, CPSR_USER | CPSR_EXEC, CPSRWriteByInstr);
Hmm. What's the expected behaviour if the saved CPSR state does not match the PC state
wrt thumb?
I'm ok if this should fail in spectacular ways, I just wanna know.
I *think* what will happen at the moment is that qemu will go into a whacky state in which
the translator will read and interpret unaligned data.
I have a pending patch set for arm to raise unaligned exceptions for mis-aligned pc. For
arm32 mode, this is fine, and we'll raise the exception. But for thumb mode, this is
architecturally impossible, and the translator will assert.
The assert is going to be a problem. There are a couple of options:
(1) TARGET_REG_PC wins: unset PC[0] and adjust CPSR[T] to match.
(2) CPSR_T wins: unset pc[0] if CPSR[T] is set, unchanged otherwise. (In the Arm ARM
psueodcode, pc[0] is hardwired to 0 in thumb mode.)
(3) Don't worry about matching PC[0] and CPSR[T], but do prevent an impossible situation
and unset PC[0] always. If PC[1] is set, and CPSR[T] is unset, then we'll raise unaligned
when the cpu restarts.
Consider this program:
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
int g;
void fortytwo(int arg) { g = 42; }
int main(int argc, char **argv) {
g = 123;
signal(SIGALRM, fortytwo); alarm(1); pause();
printf("G is %d\n", g);
}
Built for 'arm' I get
G is 42
Build -mthumb I get
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
So even without your new assert, there are some issues I need to look into before I can
get to this very interesting case :(. These are all good questions, though. I clearly have
some work to do here...
And, finally, you're missing the mc_vfp_* handling.
Yes. We don't really support that at the moment, but I'll look into how hard that might be
to add.
Warner