7.0.plugins #18

NicolasDerumigny · 2022-06-01T15:33:51Z

Updating QEMU to 7.0.
Support for CPP plugins is untested and probably do not even build.
TGC C plugins are tested and all examples work on a x86_64 host, x86_64 guest.

Signed-off-by: Peter Maydell <[email protected]>

With -cpu max we get a warning: qemu-s390x: warning: 'msa5-base' requires 'kimd-sha-512'. But dropping the -cpu max and it still runs fine. Signed-off-by: Alex Bennée <[email protected]> Message-Id: <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Tested-by: Thomas Huth <[email protected]> Signed-off-by: Thomas Huth <[email protected]>

When RI2 is 0x80000000, qemu enters an infinite loop instead of jumping backwards. Fix by adding a missing cast, like in in2_ri2(). Fixes: 8ac33cd ("Convert BRANCH AND SAVE") Signed-off-by: Ilya Leoshkevich <[email protected]> Message-Id: <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Thomas Huth <[email protected]>

When RI2 is 0x80000000, qemu enters an infinite loop instead of jumping backwards. Fix by adding a missing cast, like in in2_ri2(). Fixes: 7233f2e ("target-s390: Convert BRANCH ON CONDITION") Signed-off-by: Ilya Leoshkevich <[email protected]> Message-Id: <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Thomas Huth <[email protected]>

Add a small test in order to prevent regressions. Signed-off-by: Ilya Leoshkevich <[email protected]> Message-Id: <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Signed-off-by: Thomas Huth <[email protected]>

Race conditions can happen with the current code, because the port that was available might not be anymore by the time the server is started. By setting the port to 0, PhoneServer it will use the OS default behavior to get a free port, then we save this information so we can later configure the guest. Suggested-by: Daniel P. Berrangé <[email protected]> Signed-off-by: Beraldo Leal <[email protected]> Message-Id: <[email protected]> Signed-off-by: Thomas Huth <[email protected]>

In the conversion to cpu_ld_*_mmu, the retaddr parameter was corrupted in the one case of cpu_ldq_be_mmu. Fixes: f83bcec ("accel/tcg: Add cpu_{ld,st}*_mmu interfaces") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/902 Signed-off-by: Richard Henderson <[email protected]> Message-Id: <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Tested-by: Thomas Huth <[email protected]> Signed-off-by: Thomas Huth <[email protected]>

Commit e0220bb made cpus.c target-agnostic but didn't notice the cpu_list() function is only defined in target-specific code in "cpu.h". Move list_cpus() declaration to "exec/cpu-common.h" because this function is not softmmu-specific and can also be used by user-mode, along with moving its implementation to cpu.c, which is compiled per target. Fixes: e0220bb ("softmmu: Build target-agnostic objects once") Reported-by: Max Filippov <[email protected]> Suggested-by: Paolo Bonzini <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Message-Id: <[email protected]> Tested-by: Max Filippov <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Signed-off-by: Thomas Huth <[email protected]>

…into staging * Fixes for s390x branch instruction emulation * Fixes for the tests/avocado/boot_linux.py:BootLinuxS390X test * Re-enable the "-cpu help" output # gpg: Signature made Wed 16 Mar 2022 08:01:14 GMT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "[email protected]" # gpg: Good signature from "Thomas Huth <[email protected]>" [full] # gpg: aka "Thomas Huth <[email protected]>" [full] # gpg: aka "Thomas Huth <[email protected]>" [full] # gpg: aka "Thomas Huth <[email protected]>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * tag 'pull-request-2022-03-15v2' of https://gitlab.com/thuth/qemu: softmmu: List CPU types again accel/tcg: Fix cpu_ldq_be_mmu typo tests/avocado: start PhoneServer upfront tests/tcg/s390x: Test BRASL and BRCL with large negative offsets s390x/tcg: Fix BRCL with a large negative offset s390x/tcg: Fix BRASL with a large negative offset tests/tcg: drop -cpu max from s390x sha512-mvx invocation Signed-off-by: Peter Maydell <[email protected]>

The io_uring fixed "Don't truncate addr fields to 32-bit on 32-bit": https://git.kernel.dk/cgit/liburing/commit/?id=d84c29b19ed0b130000619cff40141bb1fc3615b This leads to build failure: ../util/fdmon-io_uring.c: In function ‘add_poll_remove_sqe’: ../util/fdmon-io_uring.c:182:36: error: passing argument 2 of ‘io_uring_prep_poll_remove’ makes integer from pointer without a cast [-Werror=int-conversion] 182 | io_uring_prep_poll_remove(sqe, node); | ^~~~ | | | AioHandler * In file included from /root/io/qemu/include/block/aio.h:18, from ../util/aio-posix.h:20, from ../util/fdmon-io_uring.c:49: /usr/include/liburing.h:415:17: note: expected ‘__u64’ {aka ‘long long unsigned int’} but argument is of type ‘AioHandler *’ 415 | __u64 user_data) | ~~~~~~^~~~~~~~~ cc1: all warnings being treated as errors Use LIBURING_HAVE_DATA64 to check whether the io_uring supports 64-bit variants of the get/set userdata, to convert the paramter to the right data type. Signed-off-by: Haiyue Wang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Stefan Hajnoczi <[email protected]>

When ->poll() succeeds the AioHandler is placed on the ready list with revents set to the magic value 0. This magic value causes aio_dispatch_handler() to invoke ->poll_ready() instead of ->io_read() for G_IO_IN or ->io_write() for G_IO_OUT. This magic value 0 hack works for the IOThread where AioHandlers are placed on ->ready_list and processed by aio_dispatch_ready_handlers(). It does not work for the main loop where all AioHandlers are processed by aio_dispatch_handlers(), even those that are not ready and have a revents value of 0. As a result the main loop invokes ->poll_ready() on AioHandlers that are not ready. These spurious ->poll_ready() calls waste CPU cycles and could lead to crashes if the code assumes ->poll() must have succeeded before ->poll_ready() is called (a reasonable asumption but I haven't seen it in practice). Stop using revents to track whether ->poll_ready() will be called on an AioHandler. Introduce a separate AioHandler->poll_ready field instead. This eliminates spurious ->poll_ready() calls in the main loop. Fixes: 826cc32 ("aio-posix: split poll check from ready handler") Signed-off-by: Stefan Hajnoczi <[email protected]> Reported-by: Jason Wang <[email protected]> Tested-by: Jason Wang <[email protected]> Message-id: [email protected] Signed-off-by: Stefan Hajnoczi <[email protected]>

GTK already produces corresponding GDK_BUTTON_PRESS events alongside 2BUTTON and 3BUTTON_PRESS events. The 2BUTTON and 3BUTTON_PRESS events were incorrectly being interpreted and passed to guests as button release events. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/558 Signed-off-by: K. Lange <[email protected]> Message-Id: <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]>

Check the dirty bits in advance to avoid unnecessary memory operations. In the case that guest surface has different format than the server, but it does not have dirty bits which means no refresh is actually needed, the memory operations is not necessary. Signed-off-by: Jianxian Wen <[email protected]> Signed-off-by: Lu Gao <[email protected]> Reviewed-by: Marc-André Lureau <[email protected]> Message-Id: <4C23C17B8E87E74E906A25A3254A03F4FA22100C@SHASXM06.verisilicon.com> Signed-off-by: Gerd Hoffmann <[email protected]>

The unused variables when FLOAT_MIXENG is defined caused warnings on Apple clang version 13.1.6 (clang-1316.0.21.2). Signed-off-by: Akihiko Odaki <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-Id: <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]>

Most of the code in this function had been indented with 5 spaces instead of 4. Since 4 is our preferred style, remove one space in the bad lines here. Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Thomas Huth <[email protected]> Message-Id: <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]>

The vga_common_init() function currently cannot report errors to its caller. But in the following patch, we'd need this possibility, so let's change it to take an "Error **" as parameter for this. Signed-off-by: Thomas Huth <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-Id: <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]>

QEMU currently abort()s if the user tries to add a second ISA VGA device, for example: $ ./qemu-system-x86_64 -device isa-vga -device isa-vga RAMBlock "vga.vram" already registered, abort! Aborted (core dumped) $ ./qemu-system-x86_64 -device isa-cirrus-vga -device isa-cirrus-vga RAMBlock "vga.vram" already registered, abort! Aborted (core dumped) $ ./qemu-system-mips64el -M pica61 -device isa-vga RAMBlock "vga.vram" already registered, abort! Aborted (core dumped) Such a crash should never happen just because of giving bad parameters at the command line. Let's return a proper error message instead. (The idea is based on an original patch by Jose R. Ziviani for the isa-vga device, but this now fixes it for the isa-cirrus-vga device, too) Resolves: https://gitlab.com/qemu-project/qemu/-/issues/44 Signed-off-by: Thomas Huth <[email protected]> Message-Id: <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]>

For both ldnt1 and stnt1, the meaning of the Rn and Rm are different from ld1 and st1: the vector and integer registers are reversed, and the integer register 31 refers to XZR instead of SP. Secondly, the 64-bit version of ldnt1 was being interpreted as 32-bit unpacked unscaled offset instead of 64-bit unscaled offset, which discarded the upper 32 bits of the address coming from the vector argument. Thirdly, validate that the memory element size is in range for the vector element size for ldnt1. For ld1, we do this via independent decode patterns, but for ldnt1 we need to do it manually. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/826 Signed-off-by: Richard Henderson <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]>

When arm_is_el2_enabled was introduced, we missed updating pauth_check_trap. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/788 Fixes: e6ef016 ("target/arm: use arm_is_el2_enabled() where applicable") Signed-off-by: Richard Henderson <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]>

LPAE descriptors come in three forms: * table descriptors, giving the address of the next level page table * page descriptors, which occur only at level 3 and describe the mapping of one page (which might be 4K, 16K or 64K) * block descriptors, which occur at higher page table levels, and describe the mapping of huge pages QEMU's page-table-walk code treats block and page entries identically, simply ORing in a number of bits from the input virtual address that depends on the level of the page table that we stopped at; we depend on the previous masking of descaddr with descaddrmask to have already cleared out the low bits of the descriptor word. This is not quite right: the address field in a block descriptor is smaller, and so there are bits which are valid address bits in a page descriptor or a table descriptor but which are not supposed to be part of the address in a block descriptor, and descaddrmask does not clear them. We previously mostly got away with this because those descriptor bits are RES0; however with FEAT_BBM (part of Armv8.4) block descriptor bit 16 is defined to be the nT bit. No emulated QEMU CPU has FEAT_BBM yet, but if the host CPU has it then we might see it when using KVM or hvf. Explicitly zero out all the descaddr bits we're about to OR vaddr bits into. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/790 Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Message-id: [email protected]

In commit 00f05c0 we gave the TYPE_XLNX_CSU_DMA object its own class struct, but forgot to update the TypeInfo::class_size accordingly. This meant that not enough memory was allocated for the class struct, and the initialization of xcdc->read in the class init function wrote off the end of the memory. Add the missing line. Found by running 'check-qtest-aarch64' with a clang address-sanitizer build, which complains: ==2542634==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61000000ab00 at pc 0x559a20aebc29 bp 0x7fff97df74d0 sp 0x7fff97df74c8 WRITE of size 8 at 0x61000000ab00 thread T0 #0 0x559a20aebc28 in xlnx_csu_dma_class_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../hw/dma/xlnx_csu_dma.c:722:16 atos-tools#1 0x559a21bf297c in type_initialize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:365:9 atos-tools#2 0x559a21bf3442 in object_class_foreach_tramp /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1070:5 atos-tools#3 0x7f09bcb641b7 in g_hash_table_foreach (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x401b7) atos-tools#4 0x559a21bf3c27 in object_class_foreach /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1092:5 atos-tools#5 0x559a21bf3c27 in object_class_get_list /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1149:5 atos-tools#6 0x559a2081a2fd in select_machine /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/vl.c:1661:24 atos-tools#7 0x559a2081a2fd in qemu_create_machine /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/vl.c:2146:35 atos-tools#8 0x559a2081a2fd in qemu_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/vl.c:3706:5 atos-tools#9 0x559a20720ed5 in main /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/main.c:49:5 atos-tools#10 0x7f09baec00b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16 atos-tools#11 0x559a2067673d in _start (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/qemu-system-aarch64+0xf4b73d) 0x61000000ab00 is located 0 bytes to the right of 192-byte region [0x61000000aa40,0x61000000ab00) allocated by thread T0 here: #0 0x559a206eeff2 in calloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/qemu-system-aarch64+0xfc3ff2) atos-tools#1 0x7f09bcb7bef0 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57ef0) atos-tools#2 0x559a21bf3442 in object_class_foreach_tramp /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1070:5 Fixes: 00f05c0 ("hw/dma/xlnx_csu_dma: Support starting a read transfer through a class method") Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Francisco Iglesias <[email protected]> Reviewed-by: Edgar E. Iglesias <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Alistair Francis <[email protected]> Message-id: [email protected]

In npcm7xx_clk_sel_init() we allocate a string with g_strdup_printf(). Use g_autofree so we free it rather than leaking it. (Detected with the clang leak sanitizer.) Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected]

We currently list the emulators in the Windows installer's dialog in an essentially random order (it's whatever glob.glob() returns them to, which is filesystem-implementation-dependent). Add a call to sorted() so they appear in alphabetical order. Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Stefan Weil <[email protected]> Reviewed-by: John Snow <[email protected]> Message-id: [email protected]

When we build our Windows installer, it emits the warning: warning 7998: ANSI targets are deprecated Fix this by making our installer a Unicode installer instead. These won't work on Win95/98/ME, but we already do not support those. See https://nsis.sourceforge.io/Docs/Chapter4.html#aunicodetarget for the documentation of the Unicode directive. Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Stefan Weil <[email protected]> Message-id: [email protected]

We use the nsis.py script to write out an installer script Section for each emulator executable, so the exact set of Sections depends on which executables were built. However the part of qemu.nsi which specifies mouse-over descriptions for each Section still has a hard-coded and very outdated list (with just i386 and alpha). This causes two problems. Firstly, if you build the installer for a configuration where you didn't build the i386 binaries you get warnings like this: warning 6000: unknown variable/constant "{Section_i386}" detected, ignoring (macro:_==:1) warning 6000: unknown variable/constant "{Section_i386w}" detected, ignoring (macro:_==:1) (this happens in our gitlab CI jobs, for instance). Secondly, most of the emulators in the generated installer don't have any mouseover text. Make nsis.py generate a second output file which has the necessary MUI_DESCRIPTION_TEXT lines for each Section it creates, so we can include that at the right point in qemu.nsi to set the mouse-over text. Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: John Snow <[email protected]> Message-id: [email protected]

CONFIG_ARM_GIC_TCG actually guards the compilation of TCG GICv3 specific files. So let's rename it into CONFIG_ARM_GICV3_TCG Signed-off-by: Eric Auger <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Message-id: [email protected] Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

In TCG mode, if gic-version=max we always select GICv3 even if CONFIG_ARM_GICV3_TCG is unset. We shall rather select GICv2. This also brings the benefit of fixing qos tests errors for tests using gic-version=max with CONFIG_ARM_GICV3_TCG unset. Signed-off-by: Eric Auger <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Message-id: [email protected] Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

Currently the CPU_LOG_INT logging misses some useful information about loads from the vector table. Add logging where we load vector table entries. This is particularly helpful for cases where the user has accidentally not put a vector table in their image at all, which can result in confusing guest crashes at startup. Here's an example of the new logging for a case where the vector table contains garbage: Loaded reset SP 0x0 PC 0x0 from vector table Loaded reset SP 0xd008f8df PC 0xf000bf00 from vector table Taking exception 3 [Prefetch Abort] on CPU 0 ...with CFSR.IACCVIOL ...BusFault with BFSR.STKERR ...taking pending nonsecure exception 3 ...loading from element 3 of non-secure vector table at 0xc ...loaded new PC 0x20000558 ---------------- IN: 0x20000558: 08000079 stmdaeq r0, {r0, r3, r4, r5, r6} (The double reset logging is the result of our long-standing "CPUs all get reset twice" weirdness; it looks a bit ugly but it'll go away if we ever fix that :-)) Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Reviewed-by: Alex Bennée <[email protected]> Message-id: [email protected]

For M-profile, the fault address is not always exposed to the guest in a fault register (for instance the BFAR bus fault address register is only updated for bus faults on data accesses, not instruction accesses). Currently we log the address only if we're putting it into a particular guest-visible register. Since we always have it, log it generically, to make logs of i-side faults a bit clearer. Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Reviewed-by: Alex Bennée <[email protected]> Message-id: [email protected]

Add an unimplemented SERDES (Serializer/Deserializer) area. Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Francisco Iglesias <[email protected]> Signed-off-by: Edgar E. Iglesias <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]>

A potential Use-after-free was reported in virtio_iommu_handle_command when using virtio-iommu: > I find a potential Use-after-free in QEMU 6.2.0, which is in > virtio_iommu_handle_command() (./hw/virtio/virtio-iommu.c). > > > Specifically, in the loop body, the variable 'buf' allocated at line 639 can be > freed by g_free() at line 659. However, if the execution path enters the loop > body again and the if branch takes true at line 616, the control will directly > jump to 'out' at line 651. At this time, 'buf' is a freed pointer, which is not > assigned with an allocated memory but used at line 653. As a result, a UAF bug > is triggered. > > > > 599 for (;;) { > ... > 615 sz = iov_to_buf(iov, iov_cnt, 0, &head, sizeof(head)); > 616 if (unlikely(sz != sizeof(head))) { > 617 tail.status = VIRTIO_IOMMU_S_DEVERR; > 618 goto out; > 619 } > ... > 639 buf = g_malloc0(output_size); > ... > 651 out: > 652 sz = iov_from_buf(elem->in_sg, elem->in_num, 0, > 653 buf ? buf : &tail, output_size); > ... > 659 g_free(buf); > > We can fix it by set ‘buf‘ to NULL after freeing it: > > > 651 out: > 652 sz = iov_from_buf(elem->in_sg, elem->in_num, 0, > 653 buf ? buf : &tail, output_size); > ... > 659 g_free(buf); > +++ buf = NULL; > 660 } Fix as suggested by the reporter. Signed-off-by: Wentao Liang <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Message-id: [email protected] Message-ID: <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

Signed-off-by: Peter Maydell <[email protected]>

v7.0.0 release

pbo-linaro · 2022-06-22T08:48:08Z

Thanks for updating this, and keeping Plugin CPP alive :)

When trying to configure (from d541d07), I ran into this error:

$ ./configure --enable-tcg-plugin-cpp --target-list=x86_64-linux-user,arm-linux-user,aarch64-linux-user,i386-linux-user
...
../meson.build:3254:2: ERROR: Tried to enter directory "tcg/plugins", which has already been visited.

Is it working for you?

NicolasDerumigny · 2022-06-22T08:56:08Z

Good catch. This is due to multiple targets not being compatible with the current integration of the TCG plugins in the build system. I'll see how this can be fixed.

pbo-linaro · 2022-06-22T09:14:09Z

Indeed, adding a single target allows to pass configure step.

During compilation, I have this error (first time). I think it's a dependency order on generated header.

$ ./configure --enable-tcg-plugin-cpp --target-list=x86_64-linux-user
$ ninja -C build
...
FAILED: tcg/plugins/libtcg-plugin-cpp-x86_64-linux-user.so.p/cpp.c.o 
cc -m64 -mcx16 -Itcg/plugins/libtcg-plugin-cpp-x86_64-linux-user.so.p -Itcg/plugins -I../tcg/plugins -Itarget/i386 -I../target/i386 -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -Ilinux-user -I../linux-user -Ilinux-user/x86_64 -I../linux-user/x86_64 -Ilibelfin -I../libelfin -I/usr/include/capstone -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/user/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/user/qemu -iquote /home/user/qemu/include -iquote /home/user/qemu/disas/libvixl -iquote /home/user/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong '-DEMULATION_MODE="user"' -fPIC -isystem../linux-headers -isystemlinux-headers -O2 -DNEED_CPU_H '-DCONFIG_TARGET="x86_64-linux-user-config-target.h"' '-DCONFIG_DEVICES="x86_64-linux-user-config-devices.h"' -MD -MQ tcg/plugins/libtcg-plugin-cpp-x86_64-linux-user.so.p/cpp.c.o -MF tcg/plugins/libtcg-plugin-cpp-x86_64-linux-user.so.p/cpp.c.o.d -o tcg/plugins/libtcg-plugin-cpp-x86_64-linux-user.so.p/cpp.c.o -c ../tcg/plugins/cpp.c
In file included from /home/user/qemu/include/hw/qdev-core.h:8,
                 from /home/user/qemu/include/hw/core/cpu.h:23,
                 from /home/user/qemu/tcg/tcg-plugin.h:38,
                 from ../tcg/plugins/cpp.c:3:
/home/user/qemu/include/qom/object.h:17:10: fatal error: qapi/qapi-builtin-types.h: No such file or directory
   17 | #include "qapi/qapi-builtin-types.h"
      |

After recompiling, it fails when linking final qemu-x86_64 binary (adding a dependency on libdl should be enough):

/usr/bin/ld: libqemu-x86_64-linux-user.fa.p/tcg_tcg-plugin.c.o: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line

Is that compiling fine on your side?

NicolasDerumigny · 2022-06-22T09:20:10Z

I have the same bug as you when using ninja, but the Makefile back-end is working fine. I'll look at the ninja dependency issue once the multiple targets have been fixed.

pbo-linaro · 2022-06-22T09:29:26Z

Only libdl stuff is missing then, to make it work!

updated: - build system: debug - plugins: (updated Arm macro) - semihosting/arm: debugging code

NicolasDerumigny · 2022-06-22T10:50:07Z

The multi-target build should now work, I'm now looking at the ninja / libdl bugs.

NicolasDerumigny · 2022-06-22T10:57:15Z

I don't reproduce neither the dependency error nor the linking one, do you still encounter it on the last version?

pbo-linaro · 2022-06-22T13:06:24Z

multi target works fine 👍

For libdl, I'm compiling on debian sid. Anyway, it's probably better to explicit dependency on libdl introduced by tcg plugins.

diff --git a/meson.build b/meson.build
index b516e74af7..9cb62c8ae8 100644
--- a/meson.build
+++ b/meson.build
@@ -621,6 +621,7 @@ endif
 spice_headers = spice.partial_dependency(compile_args: true, includes: true)
 
 rt = cc.find_library('rt', required: false)
+dl = cc.find_library('libdl', required: true)
 
 libiscsi = not_found
 if not get_option('libiscsi').auto() or have_block
@@ -3366,7 +3367,7 @@ foreach target : target_dirs
     emulator = executable(exe_name, exe['sources'],
                install: true,
                c_args: c_args,
-               dependencies: arch_deps + deps + exe['dependencies'],
+               dependencies: arch_deps + deps + exe['dependencies'] + dl,
                objects: lib.extract_all_objects(recursive: true),
                link_language: link_language,
                link_depends: [block_syms, qemu_syms] + exe.get('link_depends', []),

With this, it successfully links!

pbo-linaro · 2022-06-22T13:12:50Z

Tested plugins, everything seems ok!

PLUGIN_CPP=coverage ./build/qemu-x86_64 -tcg-plugin build/libtcg-plugin-cpp-x86_64-linux-user.so /bin/true

NicolasDerumigny · 2022-06-22T14:17:48Z

The build system has been corrected on master :).

pbo-linaro · 2022-06-22T15:13:46Z

Great! Working fine after testing.
Didn't see again the issue with header dependency as well.

Is that PR ready for integration on your side?

NicolasDerumigny · 2022-06-23T08:24:33Z

I'm still patching it as I'm working on updating a third party project that uses this QEMU-plugins, so I expect a few commits to be pushed next week. You can either merge as is and I may submit debug PRs, or wait a bit until I finish.

pbo-linaro · 2022-06-23T09:14:04Z

Is that to enhance things, or fix broken features?

NicolasDerumigny · 2022-06-23T09:20:59Z

Mostly broken features. By the way, the interface with GDB is not working anymore, as QEMU's code structure heavily changed on that part (or, at least, enough changes for me not to understand directly where the TCG-plugin patches should be applied).

pbo-linaro · 2022-06-23T09:26:31Z

As long as plugins work correctly, it should be fine to merge this.

pbo-linaro · 2022-06-23T13:04:32Z

@guillon Could you merge that please?

guillon · 2023-04-04T13:58:12Z

Merging.
Some issues persist, I will push additional commits after the merge

pm215 and others added 30 commits March 15, 2022 23:07

Update version for v7.0.0-rc0 release

d6f229f

Signed-off-by: Peter Maydell <[email protected]>

Wentao-Liang and others added 6 commits April 8, 2022 15:02

Update version for v7.0.0-rc4 release

81c7ed4

Signed-off-by: Peter Maydell <[email protected]>

Update version for v7.0.0 release

823a3f1

Signed-off-by: Peter Maydell <[email protected]>

Merge tag 'v7.0.0' into 7.0.plugins

bb7359a

v7.0.0 release

tcg-plugin: bugfix

02bbef2

tcg-plugin: CPP interface works again

d541d07

tcg-plugin: correcting build on multiple targets

6df60e2

updated: - build system: debug - plugins: (updated Arm macro) - semihosting/arm: debugging code

meson: explicitly depend on libdl when tcg-plugin is set

d43a167

elfload: updating filename

93f24b5

guillon changed the base branch from master to next/master April 4, 2023 13:56

guillon closed this Apr 4, 2023

guillon reopened this Apr 4, 2023

guillon merged commit 0ac699e into atos-tools:next/master Apr 4, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

7.0.plugins #18

7.0.plugins #18

NicolasDerumigny commented Jun 1, 2022

pbo-linaro commented Jun 22, 2022 •

edited

Loading

NicolasDerumigny commented Jun 22, 2022

pbo-linaro commented Jun 22, 2022 •

edited

Loading

NicolasDerumigny commented Jun 22, 2022

pbo-linaro commented Jun 22, 2022

NicolasDerumigny commented Jun 22, 2022

NicolasDerumigny commented Jun 22, 2022

pbo-linaro commented Jun 22, 2022

pbo-linaro commented Jun 22, 2022

NicolasDerumigny commented Jun 22, 2022

pbo-linaro commented Jun 22, 2022

NicolasDerumigny commented Jun 23, 2022

pbo-linaro commented Jun 23, 2022

NicolasDerumigny commented Jun 23, 2022

pbo-linaro commented Jun 23, 2022

pbo-linaro commented Jun 23, 2022

guillon commented Apr 4, 2023

7.0.plugins #18

7.0.plugins #18

Conversation

NicolasDerumigny commented Jun 1, 2022

pbo-linaro commented Jun 22, 2022 • edited Loading

NicolasDerumigny commented Jun 22, 2022

pbo-linaro commented Jun 22, 2022 • edited Loading

NicolasDerumigny commented Jun 22, 2022

pbo-linaro commented Jun 22, 2022

NicolasDerumigny commented Jun 22, 2022

NicolasDerumigny commented Jun 22, 2022

pbo-linaro commented Jun 22, 2022

pbo-linaro commented Jun 22, 2022

NicolasDerumigny commented Jun 22, 2022

pbo-linaro commented Jun 22, 2022

NicolasDerumigny commented Jun 23, 2022

pbo-linaro commented Jun 23, 2022

NicolasDerumigny commented Jun 23, 2022

pbo-linaro commented Jun 23, 2022

pbo-linaro commented Jun 23, 2022

guillon commented Apr 4, 2023

pbo-linaro commented Jun 22, 2022 •

edited

Loading

pbo-linaro commented Jun 22, 2022 •

edited

Loading