* [Qemu-devel] sparc crash on delayed control-transfer couples
@ 2018-02-13 21:01 Steven Seeger
2018-02-14 18:06 ` Mark Cave-Ayland
0 siblings, 1 reply; 2+ messages in thread
From: Steven Seeger @ 2018-02-13 21:01 UTC (permalink / raw)
To: QEMU Developers
Consider the following code:
0x100 cmp %g5, 3
0x104 be 0x200
0x108 b 0x300
I believe this is what is described on page 55 of the sparc v8 manual as
unpredictable behavior, where a Bicc precedes an unconditional branch.
QEMU actually crashes unless run in GDB. Single stepping will actually have a
successful compare of %g5==3 executing from 0x300.
Without GDB, qemu crashes with unaligned access at address 2 (JUMP_PC) on the
fetch.
I understand that this may be "bad code" and may be "unpredictable" but I
don't think QEMU crashing is an acceptable case. :)
I am not a SPARC expert at all (only started looking at sparc assembly
yesterday, in fact) so I am not trying to say what the correct behavior it. It
appears that the be should be a be,a, but is not. This may be a compiler bug
in what was used to compile this code.
It seems that our board (real hardware) will run at 0x200 and ignore the
branch. I am attempting to modify translate.c to do just that to see how
things go.
If anyone else has any ideas, please chime in.
Thanks to you all for what you do.
Steven
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Qemu-devel] sparc crash on delayed control-transfer couples
2018-02-13 21:01 [Qemu-devel] sparc crash on delayed control-transfer couples Steven Seeger
@ 2018-02-14 18:06 ` Mark Cave-Ayland
0 siblings, 0 replies; 2+ messages in thread
From: Mark Cave-Ayland @ 2018-02-14 18:06 UTC (permalink / raw)
To: steven.seeger, QEMU Developers
On 13/02/18 21:01, Steven Seeger wrote:
> Consider the following code:
>
> 0x100 cmp %g5, 3
> 0x104 be 0x200
> 0x108 b 0x300
>
> I believe this is what is described on page 55 of the sparc v8 manual as
> unpredictable behavior, where a Bicc precedes an unconditional branch.
>
> QEMU actually crashes unless run in GDB. Single stepping will actually have a
> successful compare of %g5==3 executing from 0x300.
>
> Without GDB, qemu crashes with unaligned access at address 2 (JUMP_PC) on the
> fetch.
>
> I understand that this may be "bad code" and may be "unpredictable" but I
> don't think QEMU crashing is an acceptable case. :)
>
> I am not a SPARC expert at all (only started looking at sparc assembly
> yesterday, in fact) so I am not trying to say what the correct behavior it. It
> appears that the be should be a be,a, but is not. This may be a compiler bug
> in what was used to compile this code.
>
> It seems that our board (real hardware) will run at 0x200 and ignore the
> branch. I am attempting to modify translate.c to do just that to see how
> things go.
>
> If anyone else has any ideas, please chime in.
>
> Thanks to you all for what you do.
Yeah this is when it starts getting tricky... I agree that QEMU
definitely shouldn't crash but trying to figure out what the behaviour
should be is the hard part.
Can you tell me a bit about your real hardware and whether it matches
the behaviour of QEMU here?
ATB,
Mark.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-02-14 18:06 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-13 21:01 [Qemu-devel] sparc crash on delayed control-transfer couples Steven Seeger
2018-02-14 18:06 ` Mark Cave-Ayland
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.