diff mbox

[3/3] Use command "monitor set debug 0" to check the connection

Message ID 1412749679-27076-4-git-send-email-yao@codesourcery.com
State New, archived
Headers

Commit Message

Yao Qi Oct. 8, 2014, 6:27 a.m. UTC 
  Nowadays, we are using command "tstatus" to send a packet to GDBserver
in order to check the connection.  However, on the target doesn't
support tracepoint, the following error is emitted before sending any
packet to GDBserver.

tstatus^M
Trace can not be run on this target.^M
(gdb) FAIL: gdb.server/server-kill.exp: tstatus

We have to choose other commands which exists on different targets, and
send a RSP packet to GDBserver.  "monitor set debug 0" is a good one.

gdb/testsuite:

2014-10-08  Yao Qi  <yao@codesourcery.com>

	* gdb.server/server-kill.exp: Execute command "monitor set debug 0"
	instead of "tstatus".
---
 gdb/testsuite/gdb.server/server-kill.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Pedro Alves Oct. 8, 2014, 2:19 p.m. UTC | #1 
On 10/08/2014 07:27 AM, Yao Qi wrote:
> Nowadays, we are using command "tstatus" to send a packet to GDBserver
> in order to check the connection.  However, on the target doesn't
> support tracepoint, the following error is emitted before sending any
> packet to GDBserver.
> 
> tstatus^M
> Trace can not be run on this target.^M
> (gdb) FAIL: gdb.server/server-kill.exp: tstatus
> 
> We have to choose other commands which exists on different targets, and
> send a RSP packet to GDBserver.  "monitor set debug 0" is a good one.
> 

Hmm, are you sure GDB didn't really send any packet to GDBserver?

That error is printed by trace_status_command, but only after calling
target_get_trace_status, which seems to me should be sending a packet.

remote_get_trace_status's exception swallowing should be
letting TARGET_CLOSE_ERROR pass through.  Is that not working?
I'm a bit confused because it seems like if that didn't work,
we should see a "qTStatus:..." error line in the logs.

So what is preventing the packet from being sent?

Thanks,
Pedro Alves
Yao Qi Oct. 9, 2014, 3:01 a.m. UTC | #2 
Pedro Alves <palves@redhat.com> writes:

> That error is printed by trace_status_command, but only after calling
> target_get_trace_status, which seems to me should be sending a packet.
>
> remote_get_trace_status's exception swallowing should be
> letting TARGET_CLOSE_ERROR pass through.  Is that not working?
> I'm a bit confused because it seems like if that didn't work,
> we should see a "qTStatus:..." error line in the logs.
>
> So what is preventing the packet from being sent?

qTStatus is disabled after receiving the empty reply during connecting
to the remote target.

(gdb) set debug remote 1
(gdb) target remote :4444
...
Sending packet: $qTStatus#49...Packet received:                                                                                                               
Packet qTStatus (trace-status) is NOT supported
...
(gdb) show remote trace-status-packet 
Support for the `qTStatus' packet is auto-detected, currently disabled.

When the test executes command "tstatus" again, remote_get_trace_status
returns -1 at the very beginning,

  if (packet_support (PACKET_qTStatus) == PACKET_DISABLE)
    return -1;

so no RSP packet is sent out.

(gdb) set debug remote 1
(gdb) tstatus 
Trace can not be run on this target.
Pedro Alves Oct. 10, 2014, 9:38 a.m. UTC | #3 
On 10/09/2014 04:01 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> That error is printed by trace_status_command, but only after calling
>> target_get_trace_status, which seems to me should be sending a packet.
>>
>> remote_get_trace_status's exception swallowing should be
>> letting TARGET_CLOSE_ERROR pass through.  Is that not working?
>> I'm a bit confused because it seems like if that didn't work,
>> we should see a "qTStatus:..." error line in the logs.
>>
>> So what is preventing the packet from being sent?
> 
> qTStatus is disabled after receiving the empty reply during connecting
> to the remote target.

Ah, thanks.  I missed that we request the trace status on connection.

So I think we should do "set remote trace-status-packet on" before
the "tstatus".

I know that the test originally didn't use "tstatus",
but it's really the packet we should be testing for exercising
that remote_get_trace_status's exception swallowing code,
which was very much related to the original bug this test covered,
see:

  https://sourceware.org/bugzilla/show_bug.cgi?id=15275

  https://sourceware.org/ml/gdb-patches/2013-03/msg00691.html

Thanks,
Pedro Alves
diff mbox

Patch

diff --git a/gdb/testsuite/gdb.server/server-kill.exp b/gdb/testsuite/gdb.server/server-kill.exp
index 0f808a9..a2e65a4 100644
--- a/gdb/testsuite/gdb.server/server-kill.exp
+++ b/gdb/testsuite/gdb.server/server-kill.exp
@@ -53,4 +53,4 @@  remote_exec target "kill -9 $server_pid"
 
 # Force GDB to talk with GDBserver, so that we can get the
 # "connection closed" error.
-gdb_test "tstatus" {Remote connection closed|Remote communication error\.  Target disconnected\.: Connection reset by peer\.}
+gdb_test "monitor set debug 0" {Remote connection closed|Remote communication error\.  Target disconnected\.: Connection reset by peer\.}