[Qemu-devel] [Bug 1263747] Re: Arm64 fails to run a binary which runs OK on real hardware
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1263747 Title: Arm64 fails to run a binary which runs OK on real hardware Status in QEMU: Fix Released Bug description: Note this is using the not-yet-upstream aarch64 patches from: https://github.com/susematz/qemu/tree/aarch64-1.6 This binary: http://oirase.annexia.org/tmp/test.gz runs OK on real aarch64 hardware. It is a statically linked Linux binary which (if successful) will print "hello, world" and exit cleanly. On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU. The following section is only if you wish to compile this binary from source, otherwise you can ignore it. First compile OCaml from: https://github.com/ocaml/ocaml (note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile). You will have to apply the one-line patch from: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html ./configure make -j1 world.opt Then do: echo 'print_endline "hello, world"' > test.ml ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test ./test To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1263747/+subscriptions
[Qemu-devel] [Bug 1263747] Re: Arm64 fails to run a binary which runs OK on real hardware
The (re)implementation of this instruction for mainline never had this bug. ** Changed in: qemu Status: New = Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1263747 Title: Arm64 fails to run a binary which runs OK on real hardware Status in QEMU: Fix Committed Bug description: Note this is using the not-yet-upstream aarch64 patches from: https://github.com/susematz/qemu/tree/aarch64-1.6 This binary: http://oirase.annexia.org/tmp/test.gz runs OK on real aarch64 hardware. It is a statically linked Linux binary which (if successful) will print hello, world and exit cleanly. On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU. The following section is only if you wish to compile this binary from source, otherwise you can ignore it. First compile OCaml from: https://github.com/ocaml/ocaml (note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile). You will have to apply the one-line patch from: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html ./configure make -j1 world.opt Then do: echo 'print_endline hello, world' test.ml ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test ./test To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1263747/+subscriptions
[Qemu-devel] [Bug 1263747] Re: Arm64 fails to run a binary which runs OK on real hardware
runs OK on real aarch64 hardware. May I know which hardware you are talking about. Is there an aarch64 hardware target available ? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1263747 Title: Arm64 fails to run a binary which runs OK on real hardware Status in QEMU: New Bug description: Note this is using the not-yet-upstream aarch64 patches from: https://github.com/susematz/qemu/tree/aarch64-1.6 This binary: http://oirase.annexia.org/tmp/test.gz runs OK on real aarch64 hardware. It is a statically linked Linux binary which (if successful) will print hello, world and exit cleanly. On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU. The following section is only if you wish to compile this binary from source, otherwise you can ignore it. First compile OCaml from: https://github.com/ocaml/ocaml (note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile). You will have to apply the one-line patch from: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html ./configure make -j1 world.opt Then do: echo 'print_endline hello, world' test.ml ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test ./test To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1263747/+subscriptions
[Qemu-devel] [Bug 1263747] Re: Arm64 fails to run a binary which runs OK on real hardware
It's an Aarch64 binary so it won't run on 32 bit ARM at all. However I guess you meant does the equivalent program run on 32 bit ARM, and the answer is yes, but that doesn't tell us much because OCaml uses separate code generators for 32 and 64 bit ARM. The binary is single threaded. I enabled tracing on qemu and got this: http://oirase.annexia.org/tmp/arm64-call-trace.txt The associate disassembly of the binary is here: http://oirase.annexia.org/tmp/arm64-disassembly.txt I'm not exactly sure which instruction fails to be emulated properly, but it looks like one of the ones in the caml_c_call function. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1263747 Title: Arm64 fails to run a binary which runs OK on real hardware Status in QEMU: New Bug description: Note this is using the not-yet-upstream aarch64 patches from: https://github.com/susematz/qemu/tree/aarch64-1.6 This binary: http://oirase.annexia.org/tmp/test.gz runs OK on real aarch64 hardware. It is a statically linked Linux binary which (if successful) will print hello, world and exit cleanly. On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU. The following section is only if you wish to compile this binary from source, otherwise you can ignore it. First compile OCaml from: https://github.com/ocaml/ocaml (note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile). You will have to apply the one-line patch from: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html ./configure make -j1 world.opt Then do: echo 'print_endline hello, world' test.ml ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test ./test To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1263747/+subscriptions
[Qemu-devel] [Bug 1263747] Re: Arm64 fails to run a binary which runs OK on real hardware
One thing I notice is that caml_c_call is the only function that uses the instruction ret xM (in all other places the code uses the default ret with implicit x30). Hmmm .. do we emulate ret xM? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1263747 Title: Arm64 fails to run a binary which runs OK on real hardware Status in QEMU: New Bug description: Note this is using the not-yet-upstream aarch64 patches from: https://github.com/susematz/qemu/tree/aarch64-1.6 This binary: http://oirase.annexia.org/tmp/test.gz runs OK on real aarch64 hardware. It is a statically linked Linux binary which (if successful) will print hello, world and exit cleanly. On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU. The following section is only if you wish to compile this binary from source, otherwise you can ignore it. First compile OCaml from: https://github.com/ocaml/ocaml (note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile). You will have to apply the one-line patch from: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html ./configure make -j1 world.opt Then do: echo 'print_endline hello, world' test.ml ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test ./test To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1263747/+subscriptions
[Qemu-devel] [Bug 1263747] Re: Arm64 fails to run a binary which runs OK on real hardware
The attached patch fixes the ret xM variant of ret. I verified that it fixes the bug. ** Patch added: 0001-arm64-Set-source-for-ret-instruction-correctly.patch https://bugs.launchpad.net/qemu/+bug/1263747/+attachment/3934836/+files/0001-arm64-Set-source-for-ret-instruction-correctly.patch -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1263747 Title: Arm64 fails to run a binary which runs OK on real hardware Status in QEMU: New Bug description: Note this is using the not-yet-upstream aarch64 patches from: https://github.com/susematz/qemu/tree/aarch64-1.6 This binary: http://oirase.annexia.org/tmp/test.gz runs OK on real aarch64 hardware. It is a statically linked Linux binary which (if successful) will print hello, world and exit cleanly. On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU. The following section is only if you wish to compile this binary from source, otherwise you can ignore it. First compile OCaml from: https://github.com/ocaml/ocaml (note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile). You will have to apply the one-line patch from: https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html ./configure make -j1 world.opt Then do: echo 'print_endline hello, world' test.ml ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test ./test To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1263747/+subscriptions
Re: [Qemu-devel] [Bug 1263747] Re: Arm64 fails to run a binary which runs OK on real hardware
On 23 December 2013 21:27, Richard Jones rjo...@redhat.com wrote: It's an Aarch64 binary so it won't run on 32 bit ARM at all. However I guess you meant does the equivalent program run on 32 bit ARM, and the answer is yes, but that doesn't tell us much because OCaml uses separate code generators for 32 and 64 bit ARM. Yes, that's why I said equivalent binary. It's a useful check because it can tell us whether the program is using things our linux-user emulation doesn't get right at all (examples: multiple threads; some interactions of signals and blocking syscalls); so it divides the bug into probably in linux-user vs probably a target-arm bug. I see you've tracked the issue down in this case, though. thanks -- PMM
