| Message ID | 20200307010051.97022-1-yuanzi@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | gdbstub: add support to Xfer:auxv:read: packet | expand |
Patchew URL: https://patchew.org/QEMU/20200307010051.97022-1-yuanzi@google.com/
Hi,
This series failed the docker-clang@ubuntu build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-ubuntu V=1 NETWORK=1
time make docker-test-clang@ubuntu SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===
LINK qemu-bridge-helper
LINK virtiofsd
LINK vhost-user-input
/usr/bin/ld/usr/bin/ld: : /lib/x86_64-linux-gnu/libtirpc.so.3/lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `: warning: common of `rpc_createerr@@GLIBC_2.2.5rpc_createerr@@GLIBC_2.2.5' overridden by definition from ' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6/lib/x86_64-linux-gnu/libc.so.6
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK qemu-img
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
GEN m68k-softmmu/hmp-commands.h
GEN microblazeel-softmmu/hmp-commands.h
GEN microblaze-softmmu/hmp-commands.h
---
CC i386-softmmu/hw/display/virtio-gpu-3d.o
CC m68k-softmmu/target/m68k/softfloat.o
CC hppa-softmmu/hw/net/virtio-net.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC aarch64-softmmu/hw/intc/exynos4210_gic.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC i386-softmmu/hw/display/vhost-user-gpu.o
CC m68k-softmmu/target/m68k/gdbstub.o
CC aarch64-softmmu/hw/intc/exynos4210_combiner.o
---
CC arm-softmmu/hw/scsi/virtio-scsi.o
CC i386-softmmu/hw/display/vhost-user-vga.o
CC aarch64-softmmu/hw/scsi/virtio-scsi.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC aarch64-softmmu/hw/scsi/virtio-scsi-dataplane.o
CC mips-softmmu/hw/net/rocker/qmp-norocker.o
CC i386-softmmu/hw/hyperv/hyperv.o
---
CC mips-softmmu/hw/mips/mips_int.o
CC mips-softmmu/hw/mips/mips_r4k.o
CC ppc-softmmu/accel/tcg/tcg-all.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC mips64el-softmmu/hw/mips/cps.o
CC nios2-softmmu/monitor/misc.o
CC moxie-softmmu/qapi/qapi-visit-machine-target.o
---
CC mips-softmmu/qapi/qapi-events-machine-target.o
CC arm-softmmu/hw/arm/musicpal.o
CC ppc-softmmu/hw/core/machine-qmp-cmds.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC or1k-softmmu/qapi/qapi-types-machine-target.o
CC aarch64-softmmu/hw/arm/microbit.o
CC or1k-softmmu/qapi/qapi-types-misc-target.o
---
CC or1k-softmmu/qapi/qapi-commands-machine-target.o
CC or1k-softmmu/qapi/qapi-commands-misc-target.o
CC i386-softmmu/hw/i386/microvm.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC ppc-softmmu/hw/display/virtio-gpu-base.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC or1k-softmmu/qapi/qapi-commands.o
CC mips64-softmmu/target/mips/translate.o
CC ppc-softmmu/hw/display/virtio-gpu.o
---
CC mips-softmmu/target/mips/translate.o
CC ppc64-softmmu/accel/stubs/whpx-stub.o
CC i386-softmmu/hw/i386/x86-iommu.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC mips64-softmmu/target/mips/op_helper.o
CC riscv32-softmmu/exec-vary.o
CC riscv32-softmmu/tcg/tcg.o
---
LINK hppa-softmmu/qemu-system-hppa
CC i386-softmmu/hw/i386/vmport.o
CC or1k-softmmu/target/openrisc/mmu.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC arm-softmmu/hw/arm/tosa.o
CC aarch64-softmmu/hw/arm/realview.o
GEN or1k-softmmu/target/openrisc/decode.inc.c
CC arm-softmmu/hw/arm/z2.o
CC or1k-softmmu/target/openrisc/exception_helper.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC or1k-softmmu/target/openrisc/fpu_helper.o
CC i386-softmmu/hw/i386/vmmouse.o
CC or1k-softmmu/target/openrisc/interrupt_helper.o
---
CC riscv32-softmmu/tcg/tcg-common.o
CC riscv64-softmmu/tcg/tcg-common.o
CC riscv32-softmmu/tcg/optimize.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
GEN trace/generated-helpers.c
CC riscv64-softmmu/tcg/optimize.o
CC riscv32-softmmu/fpu/softfloat.o
---
LINK or1k-softmmu/qemu-system-or1k
CC arm-softmmu/hw/arm/collie.o
CC arm-softmmu/hw/arm/versatilepb.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC ppc64-softmmu/hw/block/dataplane/virtio-blk.o
GEN riscv64-softmmu/gdbstub-xml.c
CC riscv32-softmmu/arch_init.o
---
CC sparc-softmmu/accel/tcg/translate-all.o
CC sparc-softmmu/accel/tcg/translator.o
CC sparc-softmmu/dump/dump.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC unicore32-softmmu/arch_init.o
CC riscv32-softmmu/hw/scsi/vhost-user-scsi.o
CC sh4-softmmu/hw/display/vga.o
---
CC s390x-softmmu/hw/vfio/pci-quirks.o
CC riscv64-softmmu/hw/virtio/vhost-user-input-pci.o
CC riscv32-softmmu/hw/virtio/virtio-iommu.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC x86_64-softmmu/exec-vary.o
CC x86_64-softmmu/tcg/tcg.o
CC sparc64-softmmu/hw/scsi/virtio-scsi-dataplane.o
---
CC aarch64-softmmu/target/arm/debug_helper.o
CC ppc64-softmmu/hw/virtio/vhost-user-fs-pci.o
GEN aarch64-softmmu/target/arm/decode-vfp.inc.c
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
GEN aarch64-softmmu/target/arm/decode-vfp-uncond.inc.c
GEN aarch64-softmmu/target/arm/decode-a32.inc.c
CC tricore-softmmu/qapi/qapi-events.o
---
CC unicore32-softmmu/target/unicore32/translate.o
CC unicore32-softmmu/target/unicore32/op_helper.o
CC unicore32-softmmu/target/unicore32/helper.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC unicore32-softmmu/target/unicore32/cpu.o
CC unicore32-softmmu/target/unicore32/ucf64_helper.o
CC riscv32-softmmu/hw/virtio/virtio-blk-pci.o
---
CC unicore32-softmmu/softmmu/main.o
CC unicore32-softmmu/trace/generated-helpers.o
LINK unicore32-softmmu/qemu-system-unicore32
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC riscv32-softmmu/hw/virtio/virtio-net-pci.o
CC riscv64-softmmu/hw/riscv/riscv_htif.o
GEN xtensa-softmmu/hmp-commands.h
---
CC sparc64-softmmu/hw/virtio/virtio.o
CC riscv32-softmmu/hw/virtio/virtio-serial-pci.o
CC sh4-softmmu/hw/virtio/vhost-backend.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC sh4-softmmu/hw/virtio/vhost-user.o
CC sh4-softmmu/hw/virtio/virtio-balloon.o
CC sh4-softmmu/hw/virtio/virtio-crypto.o
---
CC aarch64_be-linux-user/gdbstub.o
CC xtensaeb-softmmu/gdbstub.o
CC alpha-linux-user/gdbstub.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC ppc64-softmmu/hw/ppc/spapr_rtc.o
CC sh4-softmmu/qapi/qapi-events-misc-target.o
CC sh4eb-softmmu/qapi/qapi-events.o
---
CC alpha-linux-user/accel/stubs/kvm-stub.o
CC xtensaeb-softmmu/memory.o
CC s390x-softmmu/hw/s390x/virtio-ccw.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC aarch64_be-linux-user/accel/stubs/hvf-stub.o
CC sparc64-softmmu/qapi/qapi-introspect.o
CC alpha-linux-user/accel/tcg/tcg-runtime.o
---
CC hppa-linux-user/tcg/tcg-common.o
CC armeb-linux-user/accel/tcg/translate-all.o
CC hppa-linux-user/tcg/optimize.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC arm-linux-user/accel/tcg/cpu-exec-common.o
CC aarch64_be-linux-user/target/arm/translate-sve.o
CC arm-linux-user/accel/tcg/translate-all.o
---
CC hppa-linux-user/gdbstub.o
CC arm-linux-user/accel/tcg/user-exec.o
CC sparc64-softmmu/target/sparc/helper.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC armeb-linux-user/accel/tcg/user-exec-stub.o
CC sparc64-softmmu/target/sparc/cpu.o
CC armeb-linux-user/linux-user/main.o
---
CC arm-linux-user/target/arm/translate.o
LINK cris-linux-user/qemu-cris
CC xtensaeb-softmmu/hw/display/vga.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC ppc64-softmmu/hw/ppc/pnv_pnor.o
CC xtensa-softmmu/hw/net/virtio-net.o
CC hppa-linux-user/trace/generated-helpers.o
---
CC microblaze-linux-user/tcg/tcg.o
CC x86_64-softmmu/hw/vfio/pci-quirks.o
CC s390x-softmmu/qapi/qapi-visit-misc-target.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC s390x-softmmu/qapi/qapi-visit.o
CC m68k-linux-user/thunk.o
CC microblaze-linux-user/tcg/tcg-op.o
---
CC xtensaeb-softmmu/hw/virtio/virtio-net-pci.o
CC xtensaeb-softmmu/hw/virtio/virtio-serial-pci.o
CC xtensaeb-softmmu/hw/xtensa/mx_pic.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
GEN ppc64le-linux-user/config-target.h
CC ppc64le-linux-user/exec.o
GEN riscv32-linux-user/config-target.h
---
CC riscv32-linux-user/accel/tcg/cpu-exec-common.o
CC riscv64-linux-user/accel/tcg/cpu-exec.o
CC ppc64le-linux-user/accel/tcg/translator.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC riscv32-linux-user/accel/tcg/translate-all.o
CC sh4-linux-user/accel/stubs/hvf-stub.o
CC riscv64-linux-user/accel/tcg/cpu-exec-common.o
---
CC xtensa-linux-user/linux-user/mmap.o
CC xtensa-linux-user/linux-user/signal.o
CC sparc-linux-user/target/sparc/ldst_helper.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC sparc32plus-linux-user/target/sparc/int64_helper.o
CC sparc-linux-user/target/sparc/int32_helper.o
CC x86_64-linux-user/linux-user/fd-trans.o
---
CC xtensaeb-linux-user/trace/generated-helpers.o
LINK xtensaeb-linux-user/qemu-xtensaeb
LINK x86_64-softmmu/qemu-system-x86_64
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK ppc64-softmmu/qemu-system-ppc64
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK ppc-linux-user/qemu-ppc
LINK ppc64-linux-user/qemu-ppc64
LINK ppc64abi32-linux-user/qemu-ppc64abi32
---
CC f128_lt_quiet.o
CC f128_isSignalingNaN.o
CC f128M_to_ui32.o
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
CC f128M_to_ui64.o
LINK tests/test-aio-multithread
CC f128M_to_i32.o
---
CC s_propagateNaNF128UI.o
AR libtestfloat.a
LINK tests/test-thread-pool
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
AR libsoftfloat.a
LINK tests/test-hbitmap
LINK tests/test-bdrv-drain
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK tests/test-bdrv-graph-mod
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK fp-test
LINK tests/test-blockjob
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK tests/test-blockjob-txn
LINK tests/test-block-backend
LINK tests/test-block-iothread
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK tests/test-image-locking
LINK tests/test-x86-cpuid
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK tests/test-xbzrle
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK tests/test-vmstate
LINK tests/test-cutils
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK tests/test-shift128
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK tests/test-mul64
LINK tests/test-int128
LINK tests/rcutorture
---
LINK tests/test-write-threshold
LINK tests/test-crypto-hash
LINK tests/test-crypto-hmac
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
LINK tests/test-crypto-cipher
LINK tests/test-crypto-secret
LINK tests/test-crypto-tlscredsx509
---
FLOAT TEST float-to-int
FLOAT TEST sub
FLOAT TEST float-to-uint
/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of `rpc_createerr@@GLIBC_2.2.5' overridden by definition from /lib/x86_64-linux-gnu/libc.so.6
FLOAT TEST mul
FLOAT TEST mulAdd
FLOAT TEST div
---
dbus-daemon[17570]: Could not get password database information for UID of current process: User "???" unknown or no memory to allocate password entry
**
ERROR:/tmp/qemu-test/src/tests/qtest/dbus-vmstate-test.c:114:get_connection: assertion failed (err == NULL): The connection is closed (g-io-error-quark, 18)
ERROR - Bail out! ERROR:/tmp/qemu-test/src/tests/qtest/dbus-vmstate-test.c:114:get_connection: assertion failed (err == NULL): The connection is closed (g-io-error-quark, 18)
Aborted (core dumped)
cleaning up pid 17570
make: *** [/tmp/qemu-test/src/tests/Makefile.include:632: check-qtest-i386] Error 1
make: *** Waiting for unfinished jobs....
Looking for expected file 'tests/data/acpi/pc/FACP.acpihmat'
---
dbus-daemon[18974]: Could not get password database information for UID of current process: User "???" unknown or no memory to allocate password entry
**
ERROR:/tmp/qemu-test/src/tests/qtest/dbus-vmstate-test.c:114:get_connection: assertion failed (err == NULL): The connection is closed (g-io-error-quark, 18)
cleaning up pid 18974
Aborted (core dumped)
ERROR - Bail out! ERROR:/tmp/qemu-test/src/tests/qtest/dbus-vmstate-test.c:114:get_connection: assertion failed (err == NULL): The connection is closed (g-io-error-quark, 18)
make: *** [/tmp/qemu-test/src/tests/Makefile.include:632: check-qtest-x86_64] Error 1
TEST check-qtest-aarch64: tests/qtest/qom-test
TEST check-qtest-arm: tests/qtest/qos-test
TEST check-qtest-aarch64: tests/qtest/test-hmp
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=d05d74d694e7437c8f4435ebc8ca6ebb', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-mbsa8yux/src/docker-src.2020-03-06-20.07.10.28053:/var/tmp/qemu:z,ro', 'qemu:ubuntu', '/var/tmp/qemu/run', 'test-clang']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=d05d74d694e7437c8f4435ebc8ca6ebb
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-mbsa8yux/src'
make: *** [docker-run-test-clang@ubuntu] Error 2
real 23m4.334s
user 0m9.504s
The full log is available at
http://patchew.org/logs/20200307010051.97022-1-yuanzi@google.com/testing.docker-clang@ubuntu/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
On Fri, Mar 6, 2020 at 5:01 PM Lirong Yuan <yuanzi@google.com> wrote: > This allows gdb to access the target’s auxiliary vector, > which can be helpful for telling system libraries important details > about the hardware, operating system, and process. > > Signed-off-by: Lirong Yuan <yuanzi@google.com> > --- > gdbstub.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 55 insertions(+) > > diff --git a/gdbstub.c b/gdbstub.c > index 22a2d630cd..a946af7007 100644 > --- a/gdbstub.c > +++ b/gdbstub.c > @@ -2105,6 +2105,12 @@ static void handle_query_supported(GdbCmdContext > *gdb_ctx, void *user_ctx) > pstrcat(gdb_ctx->str_buf, sizeof(gdb_ctx->str_buf), > ";qXfer:features:read+"); > } > +#ifdef CONFIG_USER_ONLY > + if (gdb_ctx->s->c_cpu->opaque) { > + pstrcat(gdb_ctx->str_buf, sizeof(gdb_ctx->str_buf), > + ";qXfer:auxv:read+"); > + } > +#endif > > if (gdb_ctx->num_params && > strstr(gdb_ctx->params[0].data, "multiprocess+")) { > @@ -2166,6 +2172,47 @@ static void > handle_query_xfer_features(GdbCmdContext *gdb_ctx, void *user_ctx) > put_packet_binary(gdb_ctx->s, gdb_ctx->str_buf, len + 1, true); > } > > +#ifdef CONFIG_USER_ONLY > +static void handle_query_xfer_auxv(GdbCmdContext *gdb_ctx, void *user_ctx) > +{ > + TaskState *ts; > + unsigned long offset, len, saved_auxv, auxv_len; > + const char *mem; > + > + if (gdb_ctx->num_params < 2) { > + put_packet(gdb_ctx->s, "E22"); > + return; > + } > + > + offset = gdb_ctx->params[0].val_ul; > + len = gdb_ctx->params[1].val_ul; > + > + ts = gdb_ctx->s->c_cpu->opaque; > + saved_auxv = ts->info->saved_auxv; > + auxv_len = ts->info->auxv_len; > + mem = (const char *)(saved_auxv + offset); > + > + if (offset >= auxv_len) { > + put_packet(gdb_ctx->s, "E22"); > + return; > + } > + > + if (len > (MAX_PACKET_LENGTH - 5) / 2) { > + len = (MAX_PACKET_LENGTH - 5) / 2; > + } > + > + if (len < auxv_len - offset) { > + gdb_ctx->str_buf[0] = 'm'; > + len = memtox(gdb_ctx->str_buf + 1, mem, len); > + } else { > + gdb_ctx->str_buf[0] = 'l'; > + len = memtox(gdb_ctx->str_buf + 1, mem, auxv_len - offset); > + } > + > + put_packet_binary(gdb_ctx->s, gdb_ctx->str_buf, len + 1, true); > +} > +#endif > + > static void handle_query_attached(GdbCmdContext *gdb_ctx, void *user_ctx) > { > put_packet(gdb_ctx->s, GDB_ATTACHED); > @@ -2271,6 +2318,14 @@ static GdbCmdParseEntry gdb_gen_query_table[] = { > .cmd_startswith = 1, > .schema = "s:l,l0" > }, > +#ifdef CONFIG_USER_ONLY > + { > + .handler = handle_query_xfer_auxv, > + .cmd = "Xfer:auxv:read:", > + .cmd_startswith = 1, > + .schema = "l,l0" > + }, > +#endif > { > .handler = handle_query_attached, > .cmd = "Attached:", > -- > 2.25.1.481.gfbce0eb801-goog > > Friendly ping~ Link to the patchwork page: http://patchwork.ozlabs.org/patch/1250727/
Lirong Yuan <yuanzi@google.com> writes: > On Fri, Mar 6, 2020 at 5:01 PM Lirong Yuan <yuanzi@google.com> wrote: > >> This allows gdb to access the target’s auxiliary vector, >> which can be helpful for telling system libraries important details >> about the hardware, operating system, and process. >> >> Signed-off-by: Lirong Yuan <yuanzi@google.com> >> --- >> gdbstub.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 55 insertions(+) >> >> diff --git a/gdbstub.c b/gdbstub.c >> index 22a2d630cd..a946af7007 100644 >> --- a/gdbstub.c >> +++ b/gdbstub.c >> @@ -2105,6 +2105,12 @@ static void handle_query_supported(GdbCmdContext >> *gdb_ctx, void *user_ctx) >> pstrcat(gdb_ctx->str_buf, sizeof(gdb_ctx->str_buf), >> ";qXfer:features:read+"); >> } >> +#ifdef CONFIG_USER_ONLY >> + if (gdb_ctx->s->c_cpu->opaque) { >> + pstrcat(gdb_ctx->str_buf, sizeof(gdb_ctx->str_buf), >> + ";qXfer:auxv:read+"); >> + } >> +#endif >> >> if (gdb_ctx->num_params && >> strstr(gdb_ctx->params[0].data, "multiprocess+")) { >> @@ -2166,6 +2172,47 @@ static void >> handle_query_xfer_features(GdbCmdContext *gdb_ctx, void *user_ctx) >> put_packet_binary(gdb_ctx->s, gdb_ctx->str_buf, len + 1, true); >> } >> >> +#ifdef CONFIG_USER_ONLY >> +static void handle_query_xfer_auxv(GdbCmdContext *gdb_ctx, void *user_ctx) >> +{ >> + TaskState *ts; >> + unsigned long offset, len, saved_auxv, auxv_len; >> + const char *mem; >> + >> + if (gdb_ctx->num_params < 2) { >> + put_packet(gdb_ctx->s, "E22"); >> + return; >> + } >> + >> + offset = gdb_ctx->params[0].val_ul; >> + len = gdb_ctx->params[1].val_ul; >> + >> + ts = gdb_ctx->s->c_cpu->opaque; >> + saved_auxv = ts->info->saved_auxv; >> + auxv_len = ts->info->auxv_len; >> + mem = (const char *)(saved_auxv + offset); >> + >> + if (offset >= auxv_len) { >> + put_packet(gdb_ctx->s, "E22"); >> + return; >> + } >> + >> + if (len > (MAX_PACKET_LENGTH - 5) / 2) { >> + len = (MAX_PACKET_LENGTH - 5) / 2; >> + } >> + >> + if (len < auxv_len - offset) { >> + gdb_ctx->str_buf[0] = 'm'; >> + len = memtox(gdb_ctx->str_buf + 1, mem, len); >> + } else { >> + gdb_ctx->str_buf[0] = 'l'; >> + len = memtox(gdb_ctx->str_buf + 1, mem, auxv_len - offset); >> + } >> + >> + put_packet_binary(gdb_ctx->s, gdb_ctx->str_buf, len + 1, true); >> +} >> +#endif >> + >> static void handle_query_attached(GdbCmdContext *gdb_ctx, void *user_ctx) >> { >> put_packet(gdb_ctx->s, GDB_ATTACHED); >> @@ -2271,6 +2318,14 @@ static GdbCmdParseEntry gdb_gen_query_table[] = { >> .cmd_startswith = 1, >> .schema = "s:l,l0" >> }, >> +#ifdef CONFIG_USER_ONLY >> + { >> + .handler = handle_query_xfer_auxv, >> + .cmd = "Xfer:auxv:read:", >> + .cmd_startswith = 1, >> + .schema = "l,l0" >> + }, >> +#endif >> { >> .handler = handle_query_attached, >> .cmd = "Attached:", >> -- >> 2.25.1.481.gfbce0eb801-goog >> >> > Friendly ping~ Sorry I missed this on my radar. There was a minor re-factor of gdbstub that was just merged which will mean this patch needs a re-base to use g_string_* functions to expand stings. Also we have some simple gdbstub tests now - could we come up with a multiarch gdbstub test to verify this is working properly? > > Link to the patchwork page: > http://patchwork.ozlabs.org/patch/1250727/
On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.bennee@linaro.org> wrote: > > Lirong Yuan <yuanzi@google.com> writes: > > > On Fri, Mar 6, 2020 at 5:01 PM Lirong Yuan <yuanzi@google.com> wrote: > > > >> This allows gdb to access the target’s auxiliary vector, > >> which can be helpful for telling system libraries important details > >> about the hardware, operating system, and process. > >> > >> Signed-off-by: Lirong Yuan <yuanzi@google.com> > >> --- > >> gdbstub.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 55 insertions(+) > >> > >> diff --git a/gdbstub.c b/gdbstub.c > >> index 22a2d630cd..a946af7007 100644 > >> --- a/gdbstub.c > >> +++ b/gdbstub.c > >> @@ -2105,6 +2105,12 @@ static void handle_query_supported(GdbCmdContext > >> *gdb_ctx, void *user_ctx) > >> pstrcat(gdb_ctx->str_buf, sizeof(gdb_ctx->str_buf), > >> ";qXfer:features:read+"); > >> } > >> +#ifdef CONFIG_USER_ONLY > >> + if (gdb_ctx->s->c_cpu->opaque) { > >> + pstrcat(gdb_ctx->str_buf, sizeof(gdb_ctx->str_buf), > >> + ";qXfer:auxv:read+"); > >> + } > >> +#endif > >> > >> if (gdb_ctx->num_params && > >> strstr(gdb_ctx->params[0].data, "multiprocess+")) { > >> @@ -2166,6 +2172,47 @@ static void > >> handle_query_xfer_features(GdbCmdContext *gdb_ctx, void *user_ctx) > >> put_packet_binary(gdb_ctx->s, gdb_ctx->str_buf, len + 1, true); > >> } > >> > >> +#ifdef CONFIG_USER_ONLY > >> +static void handle_query_xfer_auxv(GdbCmdContext *gdb_ctx, void > *user_ctx) > >> +{ > >> + TaskState *ts; > >> + unsigned long offset, len, saved_auxv, auxv_len; > >> + const char *mem; > >> + > >> + if (gdb_ctx->num_params < 2) { > >> + put_packet(gdb_ctx->s, "E22"); > >> + return; > >> + } > >> + > >> + offset = gdb_ctx->params[0].val_ul; > >> + len = gdb_ctx->params[1].val_ul; > >> + > >> + ts = gdb_ctx->s->c_cpu->opaque; > >> + saved_auxv = ts->info->saved_auxv; > >> + auxv_len = ts->info->auxv_len; > >> + mem = (const char *)(saved_auxv + offset); > >> + > >> + if (offset >= auxv_len) { > >> + put_packet(gdb_ctx->s, "E22"); > >> + return; > >> + } > >> + > >> + if (len > (MAX_PACKET_LENGTH - 5) / 2) { > >> + len = (MAX_PACKET_LENGTH - 5) / 2; > >> + } > >> + > >> + if (len < auxv_len - offset) { > >> + gdb_ctx->str_buf[0] = 'm'; > >> + len = memtox(gdb_ctx->str_buf + 1, mem, len); > >> + } else { > >> + gdb_ctx->str_buf[0] = 'l'; > >> + len = memtox(gdb_ctx->str_buf + 1, mem, auxv_len - offset); > >> + } > >> + > >> + put_packet_binary(gdb_ctx->s, gdb_ctx->str_buf, len + 1, true); > >> +} > >> +#endif > >> + > >> static void handle_query_attached(GdbCmdContext *gdb_ctx, void > *user_ctx) > >> { > >> put_packet(gdb_ctx->s, GDB_ATTACHED); > >> @@ -2271,6 +2318,14 @@ static GdbCmdParseEntry gdb_gen_query_table[] = { > >> .cmd_startswith = 1, > >> .schema = "s:l,l0" > >> }, > >> +#ifdef CONFIG_USER_ONLY > >> + { > >> + .handler = handle_query_xfer_auxv, > >> + .cmd = "Xfer:auxv:read:", > >> + .cmd_startswith = 1, > >> + .schema = "l,l0" > >> + }, > >> +#endif > >> { > >> .handler = handle_query_attached, > >> .cmd = "Attached:", > >> -- > >> 2.25.1.481.gfbce0eb801-goog > >> > >> > > Friendly ping~ > > Sorry I missed this on my radar. There was a minor re-factor of gdbstub > that was just merged which will mean this patch needs a re-base to use > g_string_* functions to expand stings. > > Also we have some simple gdbstub tests now - could we come up with a > multiarch gdbstub test to verify this is working properly? > > > > > Link to the patchwork page: > > http://patchwork.ozlabs.org/patch/1250727/ > > > -- > Alex Bennée > Hi Alex, For sure, I will re-base this patch to use g_string_* functions. Currently we are using qemu aarch64. I am not sure how to do this yet, but I could try to add something to https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub Does this sound good? Thanks! Lirong
Lirong Yuan <yuanzi@google.com> writes: > On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.bennee@linaro.org> wrote: <snip> >> >> Sorry I missed this on my radar. There was a minor re-factor of gdbstub >> that was just merged which will mean this patch needs a re-base to use >> g_string_* functions to expand stings. >> >> Also we have some simple gdbstub tests now - could we come up with a >> multiarch gdbstub test to verify this is working properly? >> <snip> > For sure, I will re-base this patch to use g_string_* functions. > > Currently we are using qemu aarch64. I am not sure how to do this yet, but > I could try to add something to > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub If the auxv support is appropriate to all linux-user targets you can plumb it into the multiarch tests - you can even use the existing binaries. So you need: - a stanza in the makefiles to launch the test (see tests/tcg/aarch64/Makefile.target) - a .py test script that manipulates gdbstub to check things are working So something like: .PHONY: gdbstub-foo-binary run-gdbstub-foo-binary: foo-binary $(call run-test, $@, $(GDB_SCRIPT) \ --gdb $(HAVE_GDB_BIN) \ --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ --bin $< --test $(MULTIARCH_SRC)/gdbstub/test-foo.py, \ "basic gdbstub FOO support") > > Does this sound good? Hope that helps. > > Thanks! > Lirong
On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée <alex.bennee@linaro.org> wrote: > > Lirong Yuan <yuanzi@google.com> writes: > > > On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.bennee@linaro.org> > wrote: > <snip> > >> > >> Sorry I missed this on my radar. There was a minor re-factor of gdbstub > >> that was just merged which will mean this patch needs a re-base to use > >> g_string_* functions to expand stings. > >> > >> Also we have some simple gdbstub tests now - could we come up with a > >> multiarch gdbstub test to verify this is working properly? > >> > <snip> > > For sure, I will re-base this patch to use g_string_* functions. > > > > Currently we are using qemu aarch64. I am not sure how to do this yet, > but > > I could try to add something to > > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub > > If the auxv support is appropriate to all linux-user targets you can > plumb it into the multiarch tests - you can even use the existing > binaries. > > So you need: > > - a stanza in the makefiles to launch the test (see > tests/tcg/aarch64/Makefile.target) > > - a .py test script that manipulates gdbstub to check things are working > > So something like: > > .PHONY: gdbstub-foo-binary > run-gdbstub-foo-binary: foo-binary > $(call run-test, $@, $(GDB_SCRIPT) \ > --gdb $(HAVE_GDB_BIN) \ > --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ > --bin $< --test $(MULTIARCH_SRC)/gdbstub/test-foo.py, \ > "basic gdbstub FOO support") > > > > > > Does this sound good? > > Hope that helps. > > > > > Thanks! > > Lirong > > > -- > Alex Bennée > Hi Alex, Thanks for the instructions, very helpful! I rebased this patch to use g_string_* functions, and the link to patchwork is: http://patchwork.ozlabs.org/patch/1264125/ Could you help take another look? Regarding testing, I looked at some instructions for running tests, e.g. https://github.com/qemu/qemu/blob/master/docs/devel/testing.rst https://wiki.qemu.org/Testing However I still could not get the tests for aarch64 to run. Do you know how to run the aarch64 or multi-arch tests? Also there aren't any existing gdb stub tests that try to read uninterpreted bytes from the target’s special data area identified by a keyword: https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#qXfer-auxiliary-vector-read I looked at some other gdb stub tests, but they did not seem to send any queries: https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub So I am not sure how to set up one for "Xfer:auxv:read:" packets... Are there plans to add more tests for other packets like "Xfer:features:read:"? I'd be happy to add a test if there is an example of how to do it. :) Thanks, Lirong
Lirong Yuan <yuanzi@google.com> writes: > On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée <alex.bennee@linaro.org> wrote: > >> >> Lirong Yuan <yuanzi@google.com> writes: >> >> > On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.bennee@linaro.org> >> wrote: >> <snip> >> >> >> >> Sorry I missed this on my radar. There was a minor re-factor of gdbstub >> >> that was just merged which will mean this patch needs a re-base to use >> >> g_string_* functions to expand stings. >> >> >> >> Also we have some simple gdbstub tests now - could we come up with a >> >> multiarch gdbstub test to verify this is working properly? >> >> >> <snip> >> > For sure, I will re-base this patch to use g_string_* functions. >> > >> > Currently we are using qemu aarch64. I am not sure how to do this yet, >> but >> > I could try to add something to >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub >> >> If the auxv support is appropriate to all linux-user targets you can >> plumb it into the multiarch tests - you can even use the existing >> binaries. >> >> So you need: >> >> - a stanza in the makefiles to launch the test (see >> tests/tcg/aarch64/Makefile.target) >> >> - a .py test script that manipulates gdbstub to check things are working >> >> So something like: >> >> .PHONY: gdbstub-foo-binary >> run-gdbstub-foo-binary: foo-binary >> $(call run-test, $@, $(GDB_SCRIPT) \ >> --gdb $(HAVE_GDB_BIN) \ >> --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ >> --bin $< --test $(MULTIARCH_SRC)/gdbstub/test-foo.py, \ >> "basic gdbstub FOO support") >> >> >> > >> > Does this sound good? >> >> Hope that helps. >> >> > >> > Thanks! >> > Lirong >> >> >> -- >> Alex Bennée >> > > Hi Alex, > > Thanks for the instructions, very helpful! > > I rebased this patch to use g_string_* functions, and the link to patchwork > is: > http://patchwork.ozlabs.org/patch/1264125/ > Could you help take another look? > > Regarding testing, I looked at some instructions for running tests, e.g. > https://github.com/qemu/qemu/blob/master/docs/devel/testing.rst > https://wiki.qemu.org/Testing > However I still could not get the tests for aarch64 to run. Do you know how > to run the aarch64 or multi-arch tests? The aarch64 ones run with "make run-tcg-tests-aarch64-linux-user" add V=1 to see the details. > Also there aren't any existing gdb stub tests that try to read > uninterpreted bytes from the target’s special data area identified by a > keyword: > https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#qXfer-auxiliary-vector-read > I looked at some other gdb stub tests, but they did not seem to send any > queries: > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub > So I am not sure how to set up one for "Xfer:auxv:read:" packets... > Are there plans to add more tests for other packets like > "Xfer:features:read:"? > I'd be happy to add a test if there is an example of how to do it. :) What would you do from a normal gdb command line. At the very least you run the same command with gdb.execute(), e.g.: gdb.execute("set confirm off") is the same as typing set confirm off at the gdb command prompt. > > Thanks, > Lirong
On Mon, Mar 30, 2020 at 12:47 PM Alex Bennée <alex.bennee@linaro.org> wrote: > > Lirong Yuan <yuanzi@google.com> writes: > > > On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée <alex.bennee@linaro.org> > wrote: > > > >> > >> Lirong Yuan <yuanzi@google.com> writes: > >> > >> > On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.bennee@linaro.org> > >> wrote: > >> <snip> > >> >> > >> >> Sorry I missed this on my radar. There was a minor re-factor of > gdbstub > >> >> that was just merged which will mean this patch needs a re-base to > use > >> >> g_string_* functions to expand stings. > >> >> > >> >> Also we have some simple gdbstub tests now - could we come up with a > >> >> multiarch gdbstub test to verify this is working properly? > >> >> > >> <snip> > >> > For sure, I will re-base this patch to use g_string_* functions. > >> > > >> > Currently we are using qemu aarch64. I am not sure how to do this yet, > >> but > >> > I could try to add something to > >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub > >> > >> If the auxv support is appropriate to all linux-user targets you can > >> plumb it into the multiarch tests - you can even use the existing > >> binaries. > >> > >> So you need: > >> > >> - a stanza in the makefiles to launch the test (see > >> tests/tcg/aarch64/Makefile.target) > >> > >> - a .py test script that manipulates gdbstub to check things are > working > >> > >> So something like: > >> > >> .PHONY: gdbstub-foo-binary > >> run-gdbstub-foo-binary: foo-binary > >> $(call run-test, $@, $(GDB_SCRIPT) \ > >> --gdb $(HAVE_GDB_BIN) \ > >> --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ > >> --bin $< --test $(MULTIARCH_SRC)/gdbstub/test-foo.py, \ > >> "basic gdbstub FOO support") > >> > >> > >> > > >> > Does this sound good? > >> > >> Hope that helps. > >> > >> > > >> > Thanks! > >> > Lirong > >> > >> > >> -- > >> Alex Bennée > >> > > > > Hi Alex, > > > > Thanks for the instructions, very helpful! > > > > I rebased this patch to use g_string_* functions, and the link to > patchwork > > is: > > http://patchwork.ozlabs.org/patch/1264125/ > > Could you help take another look? > > > > Regarding testing, I looked at some instructions for running tests, e.g. > > https://github.com/qemu/qemu/blob/master/docs/devel/testing.rst > > https://wiki.qemu.org/Testing > > However I still could not get the tests for aarch64 to run. Do you know > how > > to run the aarch64 or multi-arch tests? > > The aarch64 ones run with "make run-tcg-tests-aarch64-linux-user" add > V=1 to see the details. > > > Also there aren't any existing gdb stub tests that try to read > > uninterpreted bytes from the target’s special data area identified by a > > keyword: > > > https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#qXfer-auxiliary-vector-read > > I looked at some other gdb stub tests, but they did not seem to send any > > queries: > > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub > > So I am not sure how to set up one for "Xfer:auxv:read:" packets... > > Are there plans to add more tests for other packets like > > "Xfer:features:read:"? > > I'd be happy to add a test if there is an example of how to do it. :) > > What would you do from a normal gdb command line. At the very least you > run the same command with gdb.execute(), e.g.: > > gdb.execute("set confirm off") > > is the same as typing > > set confirm off > > at the gdb command prompt. > > > > > Thanks, > > Lirong > > > -- > Alex Bennée > Hey Alex, I tried to run the test but they were skipped. Do you know if there's any other flag that needs to be set? $ make run-tcg-tests-aarch64-linux-user make[1]: Entering directory '/usr/local/google/home/yuanzi/qemu/slirp' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/usr/local/google/home/yuanzi/qemu/slirp' BUILD TCG tests for aarch64-linux-user BUILD aarch64-linux-user guest-tests SKIPPED RUN TCG tests for aarch64-linux-user RUN tests for aarch64-linux-user SKIPPED I don't think any command needs to be run. It should just send the query automatically. Could we assume that it will work the same in the test?
Lirong Yuan <yuanzi@google.com> writes: > On Mon, Mar 30, 2020 at 12:47 PM Alex Bennée <alex.bennee@linaro.org> wrote: > >> >> Lirong Yuan <yuanzi@google.com> writes: >> >> > On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée <alex.bennee@linaro.org> >> wrote: >> > >> >> >> >> Lirong Yuan <yuanzi@google.com> writes: >> >> >> >> > On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.bennee@linaro.org> >> >> wrote: >> >> <snip> >> >> >> >> >> >> Sorry I missed this on my radar. There was a minor re-factor of >> gdbstub >> >> >> that was just merged which will mean this patch needs a re-base to >> use >> >> >> g_string_* functions to expand stings. >> >> >> >> >> >> Also we have some simple gdbstub tests now - could we come up with a >> >> >> multiarch gdbstub test to verify this is working properly? >> >> >> >> >> <snip> >> >> > For sure, I will re-base this patch to use g_string_* functions. >> >> > >> >> > Currently we are using qemu aarch64. I am not sure how to do this yet, >> >> but >> >> > I could try to add something to >> >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub >> >> >> >> If the auxv support is appropriate to all linux-user targets you can >> >> plumb it into the multiarch tests - you can even use the existing >> >> binaries. >> >> >> >> So you need: >> >> >> >> - a stanza in the makefiles to launch the test (see >> >> tests/tcg/aarch64/Makefile.target) >> >> >> >> - a .py test script that manipulates gdbstub to check things are >> working >> >> >> >> So something like: >> >> >> >> .PHONY: gdbstub-foo-binary >> >> run-gdbstub-foo-binary: foo-binary >> >> $(call run-test, $@, $(GDB_SCRIPT) \ >> >> --gdb $(HAVE_GDB_BIN) \ >> >> --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ >> >> --bin $< --test $(MULTIARCH_SRC)/gdbstub/test-foo.py, \ >> >> "basic gdbstub FOO support") >> >> >> >> >> >> > >> >> > Does this sound good? >> >> >> >> Hope that helps. >> >> >> >> > >> >> > Thanks! >> >> > Lirong >> >> >> >> >> >> -- >> >> Alex Bennée >> >> >> > >> > Hi Alex, >> > >> > Thanks for the instructions, very helpful! >> > >> > I rebased this patch to use g_string_* functions, and the link to >> patchwork >> > is: >> > http://patchwork.ozlabs.org/patch/1264125/ >> > Could you help take another look? >> > >> > Regarding testing, I looked at some instructions for running tests, e.g. >> > https://github.com/qemu/qemu/blob/master/docs/devel/testing.rst >> > https://wiki.qemu.org/Testing >> > However I still could not get the tests for aarch64 to run. Do you know >> how >> > to run the aarch64 or multi-arch tests? >> >> The aarch64 ones run with "make run-tcg-tests-aarch64-linux-user" add >> V=1 to see the details. >> >> > Also there aren't any existing gdb stub tests that try to read >> > uninterpreted bytes from the target’s special data area identified by a >> > keyword: >> > >> https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#qXfer-auxiliary-vector-read >> > I looked at some other gdb stub tests, but they did not seem to send any >> > queries: >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub >> > So I am not sure how to set up one for "Xfer:auxv:read:" packets... >> > Are there plans to add more tests for other packets like >> > "Xfer:features:read:"? >> > I'd be happy to add a test if there is an example of how to do it. :) >> >> What would you do from a normal gdb command line. At the very least you >> run the same command with gdb.execute(), e.g.: >> >> gdb.execute("set confirm off") >> >> is the same as typing >> >> set confirm off >> >> at the gdb command prompt. >> >> > >> > Thanks, >> > Lirong >> >> >> -- >> Alex Bennée >> > > Hey Alex, > > I tried to run the test but they were skipped. Do you know if there's any > other flag that needs to be set? > > $ make run-tcg-tests-aarch64-linux-user > make[1]: Entering directory '/usr/local/google/home/yuanzi/qemu/slirp' > make[1]: Nothing to be done for 'all'. > make[1]: Leaving directory '/usr/local/google/home/yuanzi/qemu/slirp' > BUILD TCG tests for aarch64-linux-user > BUILD aarch64-linux-user guest-tests SKIPPED > RUN TCG tests for aarch64-linux-user > RUN tests for aarch64-linux-user SKIPPED Ahh you either need to have docker enabled or the aarch64 compilers in your path when you run configure so the test programs can be built. The details are in docs/devel/testing.rst > I don't think any command needs to be run. It should just send the query > automatically. > Could we assume that it will work the same in the test? If that is enough to exercise the code. Can we not validate the data somehow?
On Tue, Mar 31, 2020 at 12:20 AM Alex Bennée <alex.bennee@linaro.org> wrote: > > > Lirong Yuan <yuanzi@google.com> writes: > > > On Mon, Mar 30, 2020 at 12:47 PM Alex Bennée <alex.bennee@linaro.org> wrote: > > > >> > >> Lirong Yuan <yuanzi@google.com> writes: > >> > >> > On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée <alex.bennee@linaro.org> > >> wrote: > >> > > >> >> > >> >> Lirong Yuan <yuanzi@google.com> writes: > >> >> > >> >> > On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.bennee@linaro.org> > >> >> wrote: > >> >> <snip> > >> >> >> > >> >> >> Sorry I missed this on my radar. There was a minor re-factor of > >> gdbstub > >> >> >> that was just merged which will mean this patch needs a re-base to > >> use > >> >> >> g_string_* functions to expand stings. > >> >> >> > >> >> >> Also we have some simple gdbstub tests now - could we come up with a > >> >> >> multiarch gdbstub test to verify this is working properly? > >> >> >> > >> >> <snip> > >> >> > For sure, I will re-base this patch to use g_string_* functions. > >> >> > > >> >> > Currently we are using qemu aarch64. I am not sure how to do this yet, > >> >> but > >> >> > I could try to add something to > >> >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub > >> >> > >> >> If the auxv support is appropriate to all linux-user targets you can > >> >> plumb it into the multiarch tests - you can even use the existing > >> >> binaries. > >> >> > >> >> So you need: > >> >> > >> >> - a stanza in the makefiles to launch the test (see > >> >> tests/tcg/aarch64/Makefile.target) > >> >> > >> >> - a .py test script that manipulates gdbstub to check things are > >> working > >> >> > >> >> So something like: > >> >> > >> >> .PHONY: gdbstub-foo-binary > >> >> run-gdbstub-foo-binary: foo-binary > >> >> $(call run-test, $@, $(GDB_SCRIPT) \ > >> >> --gdb $(HAVE_GDB_BIN) \ > >> >> --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ > >> >> --bin $< --test $(MULTIARCH_SRC)/gdbstub/test-foo.py, \ > >> >> "basic gdbstub FOO support") > >> >> > >> >> > >> >> > > >> >> > Does this sound good? > >> >> > >> >> Hope that helps. > >> >> > >> >> > > >> >> > Thanks! > >> >> > Lirong > >> >> > >> >> > >> >> -- > >> >> Alex Bennée > >> >> > >> > > >> > Hi Alex, > >> > > >> > Thanks for the instructions, very helpful! > >> > > >> > I rebased this patch to use g_string_* functions, and the link to > >> patchwork > >> > is: > >> > http://patchwork.ozlabs.org/patch/1264125/ > >> > Could you help take another look? > >> > > >> > Regarding testing, I looked at some instructions for running tests, e.g. > >> > https://github.com/qemu/qemu/blob/master/docs/devel/testing.rst > >> > https://wiki.qemu.org/Testing > >> > However I still could not get the tests for aarch64 to run. Do you know > >> how > >> > to run the aarch64 or multi-arch tests? > >> > >> The aarch64 ones run with "make run-tcg-tests-aarch64-linux-user" add > >> V=1 to see the details. > >> > >> > Also there aren't any existing gdb stub tests that try to read > >> > uninterpreted bytes from the target’s special data area identified by a > >> > keyword: > >> > > >> https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#qXfer-auxiliary-vector-read > >> > I looked at some other gdb stub tests, but they did not seem to send any > >> > queries: > >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub > >> > So I am not sure how to set up one for "Xfer:auxv:read:" packets... > >> > Are there plans to add more tests for other packets like > >> > "Xfer:features:read:"? > >> > I'd be happy to add a test if there is an example of how to do it. :) > >> > >> What would you do from a normal gdb command line. At the very least you > >> run the same command with gdb.execute(), e.g.: > >> > >> gdb.execute("set confirm off") > >> > >> is the same as typing > >> > >> set confirm off > >> > >> at the gdb command prompt. > >> > >> > > >> > Thanks, > >> > Lirong > >> > >> > >> -- > >> Alex Bennée > >> > > > > Hey Alex, > > > > I tried to run the test but they were skipped. Do you know if there's any > > other flag that needs to be set? > > > > $ make run-tcg-tests-aarch64-linux-user > > make[1]: Entering directory '/usr/local/google/home/yuanzi/qemu/slirp' > > make[1]: Nothing to be done for 'all'. > > make[1]: Leaving directory '/usr/local/google/home/yuanzi/qemu/slirp' > > BUILD TCG tests for aarch64-linux-user > > BUILD aarch64-linux-user guest-tests SKIPPED > > RUN TCG tests for aarch64-linux-user > > RUN tests for aarch64-linux-user SKIPPED > > Ahh you either need to have docker enabled or the aarch64 compilers in > your path when you run configure so the test programs can be built. The > details are in docs/devel/testing.rst > > > I don't think any command needs to be run. It should just send the query > > automatically. > > Could we assume that it will work the same in the test? > > If that is enough to exercise the code. Can we not validate the data somehow? > > > -- > Alex Bennée Hi Alex, Thanks for the suggestions! I just installed docker and ran the tests, but got the following error messages for gdbstub tests: $ make run-tcg-tests-aarch64-linux-user ... TEST basic gdbstub support warning: while parsing target description (at line 1): Target description specified unknown architecture "aarch64" warning: Could not load XML target description; ignoring Truncated register 37 in remote 'g' packet Traceback (most recent call last): File "/usr/local/google/home/yuanzi/Documents/gdbstub-patch/qemu/tests/tcg/multiarch/gdbstub/sha1.py", line 68, in <module> if gdb.parse_and_eval('$pc') == 0: gdb.error: No registers. TEST basic gdbstub SVE support warning: while parsing target description (at line 1): Target description specified unknown architecture "aarch64" warning: Could not load XML target description; ignoring Truncated register 37 in remote 'g' packet I'm not sure if there is any additional setup needed to make those tests pass. Do you know how to fix those errors? Thanks, Lirong
Lirong Yuan <yuanzi@google.com> writes: > On Tue, Mar 31, 2020 at 12:20 AM Alex Bennée <alex.bennee@linaro.org> wrote: >> >> >> Lirong Yuan <yuanzi@google.com> writes: >> >> > On Mon, Mar 30, 2020 at 12:47 PM Alex Bennée <alex.bennee@linaro.org> wrote: >> > >> >> >> >> Lirong Yuan <yuanzi@google.com> writes: >> >> >> >> > On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée <alex.bennee@linaro.org> >> >> wrote: >> >> > >> >> >> >> >> >> Lirong Yuan <yuanzi@google.com> writes: >> >> >> >> >> >> > On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.bennee@linaro.org> >> >> >> wrote: >> >> >> <snip> >> >> >> >> >> >> >> >> Sorry I missed this on my radar. There was a minor re-factor of >> >> gdbstub >> >> >> >> that was just merged which will mean this patch needs a re-base to >> >> use >> >> >> >> g_string_* functions to expand stings. >> >> >> >> >> >> >> >> Also we have some simple gdbstub tests now - could we come up with a >> >> >> >> multiarch gdbstub test to verify this is working properly? >> >> >> >> >> >> >> <snip> >> >> >> > For sure, I will re-base this patch to use g_string_* functions. >> >> >> > >> >> >> > Currently we are using qemu aarch64. I am not sure how to do this yet, >> >> >> but >> >> >> > I could try to add something to >> >> >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub >> >> >> >> >> >> If the auxv support is appropriate to all linux-user targets you can >> >> >> plumb it into the multiarch tests - you can even use the existing >> >> >> binaries. >> >> >> >> >> >> So you need: >> >> >> >> >> >> - a stanza in the makefiles to launch the test (see >> >> >> tests/tcg/aarch64/Makefile.target) >> >> >> >> >> >> - a .py test script that manipulates gdbstub to check things are >> >> working >> >> >> >> >> >> So something like: >> >> >> >> >> >> .PHONY: gdbstub-foo-binary >> >> >> run-gdbstub-foo-binary: foo-binary >> >> >> $(call run-test, $@, $(GDB_SCRIPT) \ >> >> >> --gdb $(HAVE_GDB_BIN) \ >> >> >> --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ >> >> >> --bin $< --test $(MULTIARCH_SRC)/gdbstub/test-foo.py, \ >> >> >> "basic gdbstub FOO support") >> >> >> >> >> >> >> >> >> > >> >> >> > Does this sound good? >> >> >> >> >> >> Hope that helps. >> >> >> >> >> >> > >> >> >> > Thanks! >> >> >> > Lirong >> >> >> >> >> >> >> >> >> -- >> >> >> Alex Bennée >> >> >> >> >> > >> >> > Hi Alex, >> >> > >> >> > Thanks for the instructions, very helpful! >> >> > >> >> > I rebased this patch to use g_string_* functions, and the link to >> >> patchwork >> >> > is: >> >> > http://patchwork.ozlabs.org/patch/1264125/ >> >> > Could you help take another look? >> >> > >> >> > Regarding testing, I looked at some instructions for running tests, e.g. >> >> > https://github.com/qemu/qemu/blob/master/docs/devel/testing.rst >> >> > https://wiki.qemu.org/Testing >> >> > However I still could not get the tests for aarch64 to run. Do you know >> >> how >> >> > to run the aarch64 or multi-arch tests? >> >> >> >> The aarch64 ones run with "make run-tcg-tests-aarch64-linux-user" add >> >> V=1 to see the details. >> >> >> >> > Also there aren't any existing gdb stub tests that try to read >> >> > uninterpreted bytes from the target’s special data area identified by a >> >> > keyword: >> >> > >> >> https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#qXfer-auxiliary-vector-read >> >> > I looked at some other gdb stub tests, but they did not seem to send any >> >> > queries: >> >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub >> >> > So I am not sure how to set up one for "Xfer:auxv:read:" packets... >> >> > Are there plans to add more tests for other packets like >> >> > "Xfer:features:read:"? >> >> > I'd be happy to add a test if there is an example of how to do it. :) >> >> >> >> What would you do from a normal gdb command line. At the very least you >> >> run the same command with gdb.execute(), e.g.: >> >> >> >> gdb.execute("set confirm off") >> >> >> >> is the same as typing >> >> >> >> set confirm off >> >> >> >> at the gdb command prompt. >> >> >> >> > >> >> > Thanks, >> >> > Lirong >> >> >> >> >> >> -- >> >> Alex Bennée >> >> >> > >> > Hey Alex, >> > >> > I tried to run the test but they were skipped. Do you know if there's any >> > other flag that needs to be set? >> > >> > $ make run-tcg-tests-aarch64-linux-user >> > make[1]: Entering directory '/usr/local/google/home/yuanzi/qemu/slirp' >> > make[1]: Nothing to be done for 'all'. >> > make[1]: Leaving directory '/usr/local/google/home/yuanzi/qemu/slirp' >> > BUILD TCG tests for aarch64-linux-user >> > BUILD aarch64-linux-user guest-tests SKIPPED >> > RUN TCG tests for aarch64-linux-user >> > RUN tests for aarch64-linux-user SKIPPED >> >> Ahh you either need to have docker enabled or the aarch64 compilers in >> your path when you run configure so the test programs can be built. The >> details are in docs/devel/testing.rst >> >> > I don't think any command needs to be run. It should just send the query >> > automatically. >> > Could we assume that it will work the same in the test? >> >> If that is enough to exercise the code. Can we not validate the data somehow? >> >> >> -- >> Alex Bennée > > Hi Alex, > > Thanks for the suggestions! I just installed docker and ran the tests, > but got the following error messages for gdbstub tests: > $ make run-tcg-tests-aarch64-linux-user > ... > TEST basic gdbstub support > warning: while parsing target description (at line 1): Target > description specified unknown architecture "aarch64" > warning: Could not load XML target description; ignoring > Truncated register 37 in remote 'g' packet > Traceback (most recent call last): > File "/usr/local/google/home/yuanzi/Documents/gdbstub-patch/qemu/tests/tcg/multiarch/gdbstub/sha1.py", > line 68, in <module> > if gdb.parse_and_eval('$pc') == 0: > gdb.error: No registers. > TEST basic gdbstub SVE support > warning: while parsing target description (at line 1): Target > description specified unknown architecture "aarch64" > warning: Could not load XML target description; ignoring > Truncated register 37 in remote 'g' packet > > I'm not sure if there is any additional setup needed to make those > tests pass. Do you know how to fix those errors? The error is because the gdb you have installed doesn't understand foreign architectures. The test should have skipped in this case so I', not sure why it causes it to fail. You can either ensure you have multiarch capable gdb (this is binutils-multiarch on debian for example) or build your own gdb and point at it with --gdb in configure. > > Thanks, > Lirong
On Tue, Jul 21, 2020 at 12:50 PM Alex Bennée <alex.bennee@linaro.org> wrote: > > > Lirong Yuan <yuanzi@google.com> writes: > > > On Tue, Mar 31, 2020 at 12:20 AM Alex Bennée <alex.bennee@linaro.org> wrote: > >> > >> > >> Lirong Yuan <yuanzi@google.com> writes: > >> > >> > On Mon, Mar 30, 2020 at 12:47 PM Alex Bennée <alex.bennee@linaro.org> wrote: > >> > > >> >> > >> >> Lirong Yuan <yuanzi@google.com> writes: > >> >> > >> >> > On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée <alex.bennee@linaro.org> > >> >> wrote: > >> >> > > >> >> >> > >> >> >> Lirong Yuan <yuanzi@google.com> writes: > >> >> >> > >> >> >> > On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.bennee@linaro.org> > >> >> >> wrote: > >> >> >> <snip> > >> >> >> >> > >> >> >> >> Sorry I missed this on my radar. There was a minor re-factor of > >> >> gdbstub > >> >> >> >> that was just merged which will mean this patch needs a re-base to > >> >> use > >> >> >> >> g_string_* functions to expand stings. > >> >> >> >> > >> >> >> >> Also we have some simple gdbstub tests now - could we come up with a > >> >> >> >> multiarch gdbstub test to verify this is working properly? > >> >> >> >> > >> >> >> <snip> > >> >> >> > For sure, I will re-base this patch to use g_string_* functions. > >> >> >> > > >> >> >> > Currently we are using qemu aarch64. I am not sure how to do this yet, > >> >> >> but > >> >> >> > I could try to add something to > >> >> >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub > >> >> >> > >> >> >> If the auxv support is appropriate to all linux-user targets you can > >> >> >> plumb it into the multiarch tests - you can even use the existing > >> >> >> binaries. > >> >> >> > >> >> >> So you need: > >> >> >> > >> >> >> - a stanza in the makefiles to launch the test (see > >> >> >> tests/tcg/aarch64/Makefile.target) > >> >> >> > >> >> >> - a .py test script that manipulates gdbstub to check things are > >> >> working > >> >> >> > >> >> >> So something like: > >> >> >> > >> >> >> .PHONY: gdbstub-foo-binary > >> >> >> run-gdbstub-foo-binary: foo-binary > >> >> >> $(call run-test, $@, $(GDB_SCRIPT) \ > >> >> >> --gdb $(HAVE_GDB_BIN) \ > >> >> >> --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ > >> >> >> --bin $< --test $(MULTIARCH_SRC)/gdbstub/test-foo.py, \ > >> >> >> "basic gdbstub FOO support") > >> >> >> > >> >> >> > >> >> >> > > >> >> >> > Does this sound good? > >> >> >> > >> >> >> Hope that helps. > >> >> >> > >> >> >> > > >> >> >> > Thanks! > >> >> >> > Lirong > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> Alex Bennée > >> >> >> > >> >> > > >> >> > Hi Alex, > >> >> > > >> >> > Thanks for the instructions, very helpful! > >> >> > > >> >> > I rebased this patch to use g_string_* functions, and the link to > >> >> patchwork > >> >> > is: > >> >> > http://patchwork.ozlabs.org/patch/1264125/ > >> >> > Could you help take another look? > >> >> > > >> >> > Regarding testing, I looked at some instructions for running tests, e.g. > >> >> > https://github.com/qemu/qemu/blob/master/docs/devel/testing.rst > >> >> > https://wiki.qemu.org/Testing > >> >> > However I still could not get the tests for aarch64 to run. Do you know > >> >> how > >> >> > to run the aarch64 or multi-arch tests? > >> >> > >> >> The aarch64 ones run with "make run-tcg-tests-aarch64-linux-user" add > >> >> V=1 to see the details. > >> >> > >> >> > Also there aren't any existing gdb stub tests that try to read > >> >> > uninterpreted bytes from the target’s special data area identified by a > >> >> > keyword: > >> >> > > >> >> https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#qXfer-auxiliary-vector-read > >> >> > I looked at some other gdb stub tests, but they did not seem to send any > >> >> > queries: > >> >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub > >> >> > So I am not sure how to set up one for "Xfer:auxv:read:" packets... > >> >> > Are there plans to add more tests for other packets like > >> >> > "Xfer:features:read:"? > >> >> > I'd be happy to add a test if there is an example of how to do it. :) > >> >> > >> >> What would you do from a normal gdb command line. At the very least you > >> >> run the same command with gdb.execute(), e.g.: > >> >> > >> >> gdb.execute("set confirm off") > >> >> > >> >> is the same as typing > >> >> > >> >> set confirm off > >> >> > >> >> at the gdb command prompt. > >> >> > >> >> > > >> >> > Thanks, > >> >> > Lirong > >> >> > >> >> > >> >> -- > >> >> Alex Bennée > >> >> > >> > > >> > Hey Alex, > >> > > >> > I tried to run the test but they were skipped. Do you know if there's any > >> > other flag that needs to be set? > >> > > >> > $ make run-tcg-tests-aarch64-linux-user > >> > make[1]: Entering directory '/usr/local/google/home/yuanzi/qemu/slirp' > >> > make[1]: Nothing to be done for 'all'. > >> > make[1]: Leaving directory '/usr/local/google/home/yuanzi/qemu/slirp' > >> > BUILD TCG tests for aarch64-linux-user > >> > BUILD aarch64-linux-user guest-tests SKIPPED > >> > RUN TCG tests for aarch64-linux-user > >> > RUN tests for aarch64-linux-user SKIPPED > >> > >> Ahh you either need to have docker enabled or the aarch64 compilers in > >> your path when you run configure so the test programs can be built. The > >> details are in docs/devel/testing.rst > >> > >> > I don't think any command needs to be run. It should just send the query > >> > automatically. > >> > Could we assume that it will work the same in the test? > >> > >> If that is enough to exercise the code. Can we not validate the data somehow? > >> > >> > >> -- > >> Alex Bennée > > > > Hi Alex, > > > > Thanks for the suggestions! I just installed docker and ran the tests, > > but got the following error messages for gdbstub tests: > > $ make run-tcg-tests-aarch64-linux-user > > ... > > TEST basic gdbstub support > > warning: while parsing target description (at line 1): Target > > description specified unknown architecture "aarch64" > > warning: Could not load XML target description; ignoring > > Truncated register 37 in remote 'g' packet > > Traceback (most recent call last): > > File "/usr/local/google/home/yuanzi/Documents/gdbstub-patch/qemu/tests/tcg/multiarch/gdbstub/sha1.py", > > line 68, in <module> > > if gdb.parse_and_eval('$pc') == 0: > > gdb.error: No registers. > > TEST basic gdbstub SVE support > > warning: while parsing target description (at line 1): Target > > description specified unknown architecture "aarch64" > > warning: Could not load XML target description; ignoring > > Truncated register 37 in remote 'g' packet > > > > I'm not sure if there is any additional setup needed to make those > > tests pass. Do you know how to fix those errors? > > The error is because the gdb you have installed doesn't understand > foreign architectures. The test should have skipped in this case so I', > not sure why it causes it to fail. > > You can either ensure you have multiarch capable gdb (this is > binutils-multiarch on debian for example) or build your own gdb and > point at it with --gdb in configure. > > > > > Thanks, > > Lirong > > > -- > Alex Bennée Hmm I installed binutils-multiarch but it still did not work. The error messages are the same as the previous ones.
On Tue, Jul 21, 2020 at 1:29 PM Lirong Yuan <yuanzi@google.com> wrote: > > On Tue, Jul 21, 2020 at 12:50 PM Alex Bennée <alex.bennee@linaro.org> wrote: > > > > > > Lirong Yuan <yuanzi@google.com> writes: > > > > > On Tue, Mar 31, 2020 at 12:20 AM Alex Bennée <alex.bennee@linaro.org> wrote: > > >> > > >> > > >> Lirong Yuan <yuanzi@google.com> writes: > > >> > > >> > On Mon, Mar 30, 2020 at 12:47 PM Alex Bennée <alex.bennee@linaro.org> wrote: > > >> > > > >> >> > > >> >> Lirong Yuan <yuanzi@google.com> writes: > > >> >> > > >> >> > On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée <alex.bennee@linaro.org> > > >> >> wrote: > > >> >> > > > >> >> >> > > >> >> >> Lirong Yuan <yuanzi@google.com> writes: > > >> >> >> > > >> >> >> > On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.bennee@linaro.org> > > >> >> >> wrote: > > >> >> >> <snip> > > >> >> >> >> > > >> >> >> >> Sorry I missed this on my radar. There was a minor re-factor of > > >> >> gdbstub > > >> >> >> >> that was just merged which will mean this patch needs a re-base to > > >> >> use > > >> >> >> >> g_string_* functions to expand stings. > > >> >> >> >> > > >> >> >> >> Also we have some simple gdbstub tests now - could we come up with a > > >> >> >> >> multiarch gdbstub test to verify this is working properly? > > >> >> >> >> > > >> >> >> <snip> > > >> >> >> > For sure, I will re-base this patch to use g_string_* functions. > > >> >> >> > > > >> >> >> > Currently we are using qemu aarch64. I am not sure how to do this yet, > > >> >> >> but > > >> >> >> > I could try to add something to > > >> >> >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub > > >> >> >> > > >> >> >> If the auxv support is appropriate to all linux-user targets you can > > >> >> >> plumb it into the multiarch tests - you can even use the existing > > >> >> >> binaries. > > >> >> >> > > >> >> >> So you need: > > >> >> >> > > >> >> >> - a stanza in the makefiles to launch the test (see > > >> >> >> tests/tcg/aarch64/Makefile.target) > > >> >> >> > > >> >> >> - a .py test script that manipulates gdbstub to check things are > > >> >> working > > >> >> >> > > >> >> >> So something like: > > >> >> >> > > >> >> >> .PHONY: gdbstub-foo-binary > > >> >> >> run-gdbstub-foo-binary: foo-binary > > >> >> >> $(call run-test, $@, $(GDB_SCRIPT) \ > > >> >> >> --gdb $(HAVE_GDB_BIN) \ > > >> >> >> --qemu $(QEMU) --qargs "$(QEMU_OPTS)" \ > > >> >> >> --bin $< --test $(MULTIARCH_SRC)/gdbstub/test-foo.py, \ > > >> >> >> "basic gdbstub FOO support") > > >> >> >> > > >> >> >> > > >> >> >> > > > >> >> >> > Does this sound good? > > >> >> >> > > >> >> >> Hope that helps. > > >> >> >> > > >> >> >> > > > >> >> >> > Thanks! > > >> >> >> > Lirong > > >> >> >> > > >> >> >> > > >> >> >> -- > > >> >> >> Alex Bennée > > >> >> >> > > >> >> > > > >> >> > Hi Alex, > > >> >> > > > >> >> > Thanks for the instructions, very helpful! > > >> >> > > > >> >> > I rebased this patch to use g_string_* functions, and the link to > > >> >> patchwork > > >> >> > is: > > >> >> > http://patchwork.ozlabs.org/patch/1264125/ > > >> >> > Could you help take another look? > > >> >> > > > >> >> > Regarding testing, I looked at some instructions for running tests, e.g. > > >> >> > https://github.com/qemu/qemu/blob/master/docs/devel/testing.rst > > >> >> > https://wiki.qemu.org/Testing > > >> >> > However I still could not get the tests for aarch64 to run. Do you know > > >> >> how > > >> >> > to run the aarch64 or multi-arch tests? > > >> >> > > >> >> The aarch64 ones run with "make run-tcg-tests-aarch64-linux-user" add > > >> >> V=1 to see the details. > > >> >> > > >> >> > Also there aren't any existing gdb stub tests that try to read > > >> >> > uninterpreted bytes from the target’s special data area identified by a > > >> >> > keyword: > > >> >> > > > >> >> https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#qXfer-auxiliary-vector-read > > >> >> > I looked at some other gdb stub tests, but they did not seem to send any > > >> >> > queries: > > >> >> > https://github.com/qemu/qemu/tree/master/tests/tcg/aarch64/gdbstub > > >> >> > So I am not sure how to set up one for "Xfer:auxv:read:" packets... > > >> >> > Are there plans to add more tests for other packets like > > >> >> > "Xfer:features:read:"? > > >> >> > I'd be happy to add a test if there is an example of how to do it. :) > > >> >> > > >> >> What would you do from a normal gdb command line. At the very least you > > >> >> run the same command with gdb.execute(), e.g.: > > >> >> > > >> >> gdb.execute("set confirm off") > > >> >> > > >> >> is the same as typing > > >> >> > > >> >> set confirm off > > >> >> > > >> >> at the gdb command prompt. > > >> >> > > >> >> > > > >> >> > Thanks, > > >> >> > Lirong > > >> >> > > >> >> > > >> >> -- > > >> >> Alex Bennée > > >> >> > > >> > > > >> > Hey Alex, > > >> > > > >> > I tried to run the test but they were skipped. Do you know if there's any > > >> > other flag that needs to be set? > > >> > > > >> > $ make run-tcg-tests-aarch64-linux-user > > >> > make[1]: Entering directory '/usr/local/google/home/yuanzi/qemu/slirp' > > >> > make[1]: Nothing to be done for 'all'. > > >> > make[1]: Leaving directory '/usr/local/google/home/yuanzi/qemu/slirp' > > >> > BUILD TCG tests for aarch64-linux-user > > >> > BUILD aarch64-linux-user guest-tests SKIPPED > > >> > RUN TCG tests for aarch64-linux-user > > >> > RUN tests for aarch64-linux-user SKIPPED > > >> > > >> Ahh you either need to have docker enabled or the aarch64 compilers in > > >> your path when you run configure so the test programs can be built. The > > >> details are in docs/devel/testing.rst > > >> > > >> > I don't think any command needs to be run. It should just send the query > > >> > automatically. > > >> > Could we assume that it will work the same in the test? > > >> > > >> If that is enough to exercise the code. Can we not validate the data somehow? > > >> > > >> > > >> -- > > >> Alex Bennée > > > > > > Hi Alex, > > > > > > Thanks for the suggestions! I just installed docker and ran the tests, > > > but got the following error messages for gdbstub tests: > > > $ make run-tcg-tests-aarch64-linux-user > > > ... > > > TEST basic gdbstub support > > > warning: while parsing target description (at line 1): Target > > > description specified unknown architecture "aarch64" > > > warning: Could not load XML target description; ignoring > > > Truncated register 37 in remote 'g' packet > > > Traceback (most recent call last): > > > File "/usr/local/google/home/yuanzi/Documents/gdbstub-patch/qemu/tests/tcg/multiarch/gdbstub/sha1.py", > > > line 68, in <module> > > > if gdb.parse_and_eval('$pc') == 0: > > > gdb.error: No registers. > > > TEST basic gdbstub SVE support > > > warning: while parsing target description (at line 1): Target > > > description specified unknown architecture "aarch64" > > > warning: Could not load XML target description; ignoring > > > Truncated register 37 in remote 'g' packet > > > > > > I'm not sure if there is any additional setup needed to make those > > > tests pass. Do you know how to fix those errors? > > > > The error is because the gdb you have installed doesn't understand > > foreign architectures. The test should have skipped in this case so I', > > not sure why it causes it to fail. > > > > You can either ensure you have multiarch capable gdb (this is > > binutils-multiarch on debian for example) or build your own gdb and > > point at it with --gdb in configure. > > > > > > > > Thanks, > > > Lirong > > > > > > -- > > Alex Bennée > > Hmm I installed binutils-multiarch but it still did not work. The > error messages are the same as the previous ones. Turns out that it can be fixed by installing gdb-multiarch and rerunning configure. I submitted a new patch, and here is the link to patchwork. :) http://patchwork.ozlabs.org/project/qemu-devel/patch/20200730193932.3654677-1-yuanzi@google.com/
diff --git a/gdbstub.c b/gdbstub.c index 22a2d630cd..a946af7007 100644 --- a/gdbstub.c +++ b/gdbstub.c @@ -2105,6 +2105,12 @@ static void handle_query_supported(GdbCmdContext *gdb_ctx, void *user_ctx) pstrcat(gdb_ctx->str_buf, sizeof(gdb_ctx->str_buf), ";qXfer:features:read+"); } +#ifdef CONFIG_USER_ONLY + if (gdb_ctx->s->c_cpu->opaque) { + pstrcat(gdb_ctx->str_buf, sizeof(gdb_ctx->str_buf), + ";qXfer:auxv:read+"); + } +#endif if (gdb_ctx->num_params && strstr(gdb_ctx->params[0].data, "multiprocess+")) { @@ -2166,6 +2172,47 @@ static void handle_query_xfer_features(GdbCmdContext *gdb_ctx, void *user_ctx) put_packet_binary(gdb_ctx->s, gdb_ctx->str_buf, len + 1, true); } +#ifdef CONFIG_USER_ONLY +static void handle_query_xfer_auxv(GdbCmdContext *gdb_ctx, void *user_ctx) +{ + TaskState *ts; + unsigned long offset, len, saved_auxv, auxv_len; + const char *mem; + + if (gdb_ctx->num_params < 2) { + put_packet(gdb_ctx->s, "E22"); + return; + } + + offset = gdb_ctx->params[0].val_ul; + len = gdb_ctx->params[1].val_ul; + + ts = gdb_ctx->s->c_cpu->opaque; + saved_auxv = ts->info->saved_auxv; + auxv_len = ts->info->auxv_len; + mem = (const char *)(saved_auxv + offset); + + if (offset >= auxv_len) { + put_packet(gdb_ctx->s, "E22"); + return; + } + + if (len > (MAX_PACKET_LENGTH - 5) / 2) { + len = (MAX_PACKET_LENGTH - 5) / 2; + } + + if (len < auxv_len - offset) { + gdb_ctx->str_buf[0] = 'm'; + len = memtox(gdb_ctx->str_buf + 1, mem, len); + } else { + gdb_ctx->str_buf[0] = 'l'; + len = memtox(gdb_ctx->str_buf + 1, mem, auxv_len - offset); + } + + put_packet_binary(gdb_ctx->s, gdb_ctx->str_buf, len + 1, true); +} +#endif + static void handle_query_attached(GdbCmdContext *gdb_ctx, void *user_ctx) { put_packet(gdb_ctx->s, GDB_ATTACHED); @@ -2271,6 +2318,14 @@ static GdbCmdParseEntry gdb_gen_query_table[] = { .cmd_startswith = 1, .schema = "s:l,l0" }, +#ifdef CONFIG_USER_ONLY + { + .handler = handle_query_xfer_auxv, + .cmd = "Xfer:auxv:read:", + .cmd_startswith = 1, + .schema = "l,l0" + }, +#endif { .handler = handle_query_attached, .cmd = "Attached:",
This allows gdb to access the target’s auxiliary vector, which can be helpful for telling system libraries important details about the hardware, operating system, and process. Signed-off-by: Lirong Yuan <yuanzi@google.com> --- gdbstub.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+)