From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Michael Snyder <msnyder@vmware.com>, Stan Shebs <stan@codesourcery.com>
Subject: Re: [RFA] gdb.trace/*.exp send_gdb vs. gdb_test
Date: Thu, 27 May 2010 23:25:00 -0000 [thread overview]
Message-ID: <201005280015.41580.pedro@codesourcery.com> (raw)
In-Reply-To: <201005272350.40581.pedro@codesourcery.com>
On Thursday 27 May 2010 23:50:40, Pedro Alves wrote:
> Let me try to fix that before you commit. Should be simple.
> Other tests had the same issue, and I thought I had fixed them
> all, but obviously this one slipped.
Oh bummer. The patch pasted at the end fixes that, but...
gdb.sum:
Running target native-gdbserver
Running ../../../src/gdb/testsuite/gdb.trace/limits.exp ...
FAIL: gdb.trace/limits.exp: maint packet QTLimit:tp:ffffffff
PASS: gdb.trace/limits.exp: This test cannot be run on this target
=== gdb Summary ===
# of expected passes 1
# of unexpected failures 1
gdb.log:
(gdb) maint packet QTLimit:tp:ffffffff
sending: "QTLimit:tp:ffffffff"
received: ""
(gdb) FAIL: gdb.trace/limits.exp: maint packet QTLimit:tp:ffffffff
... the test is using an undocumented packet to set
artificial limits on the remote tracing engine. GDBserver doesn't
implement that packet. I had never heard of this packet, and I'm
not sure it makes much sense to have this test nowadays. Can we
just get rid of the whole test file?
Otherwise, the "doesn't support this packet" detection looks bogus:
if [gdb_test "maint packet QTLimit:tp:ffffffff" \
"received: .OK." ""] then {
pass "This test cannot be run on this target"
return 1;
}
The test is skipped if the target returns something that
contains "OK" ??
---
gdb/testsuite/gdb.trace/limits.exp | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
Index: src/gdb/testsuite/gdb.trace/limits.exp
===================================================================
--- src.orig/gdb/testsuite/gdb.trace/limits.exp 2010-05-28 00:08:29.000000000 +0100
+++ src/gdb/testsuite/gdb.trace/limits.exp 2010-05-28 00:08:18.000000000 +0100
@@ -22,6 +22,7 @@ if $tracelevel then {
set testfile "limits"
set srcfile ${testfile}.c
+set executable $testfile
set binfile $objdir/$subdir/$testfile
if { [gdb_compile "$srcdir/$subdir/$srcfile" $binfile \
@@ -294,11 +295,9 @@ proc gdb_trace_limits_tests { } {
# Start with a fresh gdb.
-gdb_exit
-gdb_start
-gdb_reinitialize_dir $srcdir/$subdir
-gdb_load $binfile
-
+clean_restart $executable
+runto_main
+
if [target_info exists gdb_stub] {
gdb_step_for_stub;
}
next prev parent reply other threads:[~2010-05-27 23:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-27 18:22 Michael Snyder
2010-05-27 18:44 ` Pedro Alves
2010-05-27 19:14 ` Michael Snyder
2010-05-27 23:15 ` Pedro Alves
2010-05-27 23:25 ` Pedro Alves [this message]
2010-05-28 0:18 ` Michael Snyder
2010-05-29 0:41 ` Pedro Alves
2010-06-02 19:42 ` Michael Snyder
2010-06-02 21:58 ` Pedro Alves
2010-06-02 22:08 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201005280015.41580.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=msnyder@vmware.com \
--cc=stan@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox