On Mon, Mar 30, 2020 at 12:47 PM Alex Bennée <alex.ben...@linaro.org> wrote:
> > Lirong Yuan <yua...@google.com> writes: > > > On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée <alex.ben...@linaro.org> > wrote: > > > >> > >> Lirong Yuan <yua...@google.com> writes: > >> > >> > On Fri, Mar 20, 2020 at 2:17 AM Alex Bennée <alex.ben...@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?
