On Thu, Oct 28, 2021 at 11:53 AM Richard Henderson <
richard.hender...@linaro.org> wrote:

> 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

Reply via email to