Thread (17 messages) 17 messages, 2 authors, 2015-12-08
DORMANTno replies
Revisions (6)
  1. v5 [diff vs current]
  2. v5 [diff vs current]
  3. v9 [diff vs current]
  4. v9 [diff vs current]
  5. v9 current
  6. v10 [diff vs current]

[PATCH v9 6/6] tests/guest-debug: introduce basic gdbstub tests

From: Alex Bennée <hidden>
Date: 2015-12-08 12:02:11
Also in: kvm, kvmarm, qemu-arm, qemu-devel

Peter Maydell [off-list ref] writes:
On 12 November 2015 at 16:20, Alex Benn?e [off-list ref] wrote:
quoted
From: Alex Benn?e <redacted>

The aim of these tests is to combine with an appropriate kernel
image (with symbol-file vmlinux) and check it behaves as it should.
Given a kernel it checks:

  - single step
  - software breakpoint
  - hardware breakpoint
  - access, read and write watchpoints

On success it returns 0 to the calling process.

I've not plumbed this into the "make check" logic though as we need a
solution for providing non-host binaries to the tests. However the test
is structured to work with pretty much any Linux kernel image as it
uses the basic kernel_init code which is common across architectures.
Do these tests pass if you run them on the TCG QEMU, just out
of interest?
You'll be glad to know they do.
I'm not a great fan of tests that aren't in 'make check'
because IME they just bitrot, but as you say we have no
sensible approach for handling tests that need to run real
guest code :-(
I was pondering if a git sub-project with large file support would work.
We could add pre-built binaries to the tree with appropriate meta-data
(src tree, version, config) to rebuild if required.

There would be some degree of trust implied in the original builder
though. Maybe a signed commit?
thanks
-- PMM

--
Alex Benn?e
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help