Errors running qom-test of make check-qtest-bfin
Closed this issue · 7 comments
I apologize, as this may be more of a support request than a bug per se.
I'm attempting to get the tests (make check) to pass for the bfin branch here. I was able to get past my first stumbling block, but currently am getting an error when running the qom-test.
Naively running the test, yields:
$ make check-qtest-bfin V=1q
# <SNIP>
PASS 54 qtest-bfin/qmp-cmd-test /bfin/qmp/object-add-failure-modes
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/hans/qemu-blackfin/tests/dbus-vmstate-daemon.sh QTEST_QEMU_BINARY=./qemu-system-bfin tests/qtest/qom-test --tap -k
qemu-system-bfin: ../softmmu/physmem.c:1666: qemu_ram_set_idstr: Assertion `!new_block->idstr[0]' failed.
Broken pipe
../tests/qtest/libqtest.c:181: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
ERROR qtest-bfin/qom-test - too few tests run (expected 3, got 0)
make[1]: *** [Makefile.mtest:1353: run-test-167] Error 1
make[1]: Leaving directory '/home/hans/qemu-blackfin/build'
make: *** [GNUmakefile:11: check-qtest-bfin] Error 2
Under the hood this is the command being executed:
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/hans/qemu-blackfin/tests/dbus-vmstate-daemon.sh QTEST_QEMU_BINARY=./qemu-system-bfin gdb --args tests/qtest/qom-test --tap -k
Furthermore executing qemu-system-bfin ./qtest-img with gdb yields:
WARNING: Image format was not specified for 'qemu-img' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
qemu-system-bfin: ../softmmu/physmem.c:1666: qemu_ram_set_idstr: Assertion `!new_block->idstr[0]' failed.
Thread 1 "qemu-system-bfi" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x0000fffff67e8d68 in __GI_abort () at abort.c:79
#2 0x0000fffff67f5674 in __assert_fail_base
(fmt=0xfffff68f06c8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0xaaaaaafa81e0 "!new_block->idstr[0]", file=file@entry=0xaaaaaafa7bb0 "../softmmu/physmem.c", line=line@entry=1666, function=function@entry=0xaaaaaafa8af8 <__PRETTY_FUNCTION__.41919> "qemu_ram_set_idstr") at assert.c:92
#3 0x0000fffff67f56dc in __GI___assert_fail
(assertion=assertion@entry=0xaaaaaafa81e0 "!new_block->idstr[0]", file=file@entry=0xaaaaaafa7bb0 "../softmmu/physmem.c", line=line@entry=1666, function=function@entry=0xaaaaaafa8af8 <__PRETTY_FUNCTION__.41919> "qemu_ram_set_idstr") at assert.c:101
#4 0x0000aaaaaacaf15c in qemu_ram_set_idstr (new_block=0xaaaaab61c020, name=0xaaaaab61bf00 "L1 Data A", dev=<optimized out>) at ../softmmu/physmem.c:1666
#5 0x0000aaaaaac56918 in vmstate_register_ram (mr=mr@entry=0xaaaaab5f9300, dev=dev@entry=0x0) at ../migration/savevm.c:3032
#6 0x0000aaaaaac56960 in vmstate_register_ram_global (mr=mr@entry=0xaaaaab5f9300) at ../migration/savevm.c:3045
#7 0x0000aaaaaac97aac in bfin_memory_init (mem_layout=0xaaaaab471800 <bf537_mem>, ram_size=67108864) at ../hw/bfin/bfin_boards.c:52
#8 bfin_common_init (mem_layout=0xaaaaab471800 <bf537_mem>, ram_size=67108864, cpu_model=<synthetic pointer>, kernel_cmdline=0xaaaaab0093b0 "", kernel_filename=0x0)
at ../hw/bfin/bfin_boards.c:101
#9 bf537_stamp_init (machine=<optimized out>) at ../hw/bfin/bfin_boards.c:138
#10 0x0000aaaaaac81b34 in machine_run_board_init (machine=machine@entry=0xaaaaab5cec00) at ../hw/core/machine.c:1134
#11 0x0000aaaaaacc9080 in qemu_init (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/vl.c:4369
#12 0x0000aaaaaabd8c94 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:49
Is this an expected failure with the qtest-img -- and is there some other image I could use to validate the qemu-blackfin build?
Thanks in advance!
the only tests i run are the tcg ones via make -C tests/tcg/bfin/ -j4 since the point of this fork is to add a Blackfin backend. i assume all the other tests are handled by QEMU mainline, and since i'm not extending any of them, the tests don't add value.
Thanks so much for getting back to me. Ok, that is helpful context. I was using make check to get a sense for whether there was additional work needed in the branch before working on some packaging. I suppose I should have just asked that directly :)
Yes, in this case it appears that the tests fail because qemu-system-bfin fails to start with the qtest qemu-img image. It is a standard test suite that is running against the qemu-system-bfin machine. I'm sure you gathered that, though, from the trace / qtest command.
This is a bit of a tangent from the specific question above, but is there a reference image (LDR, as I understand it) that I can use to make sure our built version of the emulator is functional? Apologies if this is a naive question; my background is on the packaging side -- not experienced with these devices.
qemu-system-bfin is not currently usable, so don't bother. i'm still slowly figuring out how to implement all the different features that qemu requires. i tend to bang on this in my spare time when traveling, but due to COVID, i haven't traveled in a while :(.
qemu-bfin (user mode) should be good to go currently though. that's what all the TCG tests check.
i'll make a note to update the README in the bfin branch to make the port status clear.
(if you want, i can bore you with info about Blackfin executable formats, but i'm guessing you don't actually care :D)
Oh, I'd happily listen to anything re: executable formats! :). I'm reading the docs I can find. I think I see utilities I can use to build some example binaries for testing with user mode. Thank you for clarifying, though, re: qemu-system-bfin; I won't spent more time trying to get that to pass. And of course if we end up investing engineering time trying to add any functionality here, we'll create MRs. Thanks again! And here's to hoping that 2022 starts to bring more travel.
While it is further from the original intent here, wondering if you could point me to a "hello world" I could validate using user mode bfin-qemu / (and later) qemu-bfin user emulators -- just to ensure that my build is functional. I see the blink example for a couple boards in the original GCC toolchain, but unclear whether I should be able to execute that binary with a qemu user-mode emulator. I imagine the LDR is what one would load onto the actual board in that case. Appreciate any help steering me in the right direction.
oh fun, git rebases start tagging unrelated GH issues. i guess that's one way to get a heads up that i've updated to qemu-6.1.0. looks like there's more rebase work for 6.2.0 that i need to unwind that will require even more time, so i put a pause on that.
i set the default README.md in this repo to point to the blackfin one and updated that with current userland/system/testing status info. hopefully that makes things a lot more clear.
i posted the binaries i use for testing QEMU:
https://github.com/vapier/qemu/releases/tag/initial
if you want to check userland code, you can just download the busybox.xz and that's it.
wrt file formats ...
- LDR -- Blackfin "loader" format understood by the on-chip bootrom. if you take a dump of the bootrom and build it into the GNU Simulator, you could actually boot LDR files. i used to do that for fun. but there's no support for this in QEMU atm since this heavily relies on system mode resources that don't work in QEMU. would really only be used by bare metal programs (largely the bootloader and maybe an RTOS), and i suspect you don't really care about simulating those atm.
- ELF -- bare metal programs (including bootloaders like u-boot and kernels like Linux) use this format. the GNU Simulator can handle these well, both from a format, and from a "it actually runs" perspective. QEMU can handle the format, but doesn't support system mode, so only really simple bare metal programs work.
- FDPIC ELF -- your standard Linux usermode programs. these should work in both the GNU Simulator and in this QEMU userland port. building a static FDPIC ELF binary tends to simplify things so you don't have to worry about setting up the sysroot to dynamically find & load the shareds libs. although this does work in both simulators if you really wanted to :P. the busybox.xz i attached above is this format.
- FLAT -- your other standard Linux usermode program. the GNU Simulator doesn't support this format, but QEMU is supposed to. QEMU has a rocky history here though as it isn't super common, and even for more (relatively speaking) popular arches like ARM, the FLAT format itself doesn't seem to get a lot of feedback in QEMU. i've had to fix some bugs in the FLAT layers specifically. if your goal is checking blackfin code, i wouldn't bother with this as most of the bugs you'll find aren't blackfin specific.
- BINARY -- usually an ELF converted to binary data and then loaded as a blob into RAM. it's possible to load this into the GNU Simulator with a little effort. this would only work for system mode QEMU, and since that doesn't work currently for blackfin currently, can just ignore it.