gdbstub.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+)
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
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/
--
Alex Bennée
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
--
Alex Bennée
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
--
Alex Bennée
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?
--
Alex Bennée
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
--
Alex Bennée
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/
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
© 2016 - 2024 Red Hat, Inc.