This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Upload TSVs in extend-remote mode
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 20 Jun 2013 19:34:50 +0100
- Subject: Re: [PATCH] Upload TSVs in extend-remote mode
- References: <1371636174-9822-1-git-send-email-yao at codesourcery dot com>
On 06/19/2013 11:02 AM, Yao Qi wrote:
> Hi,
> In extended-remote, when GDB connects the target, but target is not
> running, the TSVs are not uploaded (because remote_start_remote
> returns earlier when the reply to packet '?' is either 'X' or 'W').
>
> However, GDBserver has some builtin or predefined TSVs to upload, such
> as $trace_timestamp. This bug causes $trace_timestamp is never uploaded.
>
> The fix to this problem is to upload TSV in
> extended_remote_create_inferior_1.
This fixes "run", but I imagine it leaves "attach" broken?
> Another fix could be that move the code uploading TSVs earlier in
> remote_start_remote before sending packet '?'. I don't choose this
> approach because I'd like GDB to upload TSVs when inferior starts run,
> instead of when GDB connects to the stub.
Why would you like that? (Not saying it might not make sense).
>
> The patch to gdb.trace/tsv.exp can expose this bug by checking 'info
> tvariables' after connect to the remote. If only test part of this
> patch is applied, we can get a fail,
>
> $ make check RUNTESTFLAGS="--target_board=native-extended-gdbserver tsv.exp"
> FAIL: gdb.trace/tsv.exp: check uploaded tsv (pattern 1)
>
> With the whole patch applied, the fail goes away.
>
> I notice that TSV "$trace_timestamp" is not a documented TSV, so stubs
> other than GDBserver may not have it. If it is a concern, I am OK to
> drop the tsv.exp part from this patch.
I recently added some code in gdb.trace/qtro.exp that probes
for GDBserver:
# Check whether we're testing with our own GDBserver.
set is_gdbserver -1
set test "probe for GDBserver"
gdb_test_multiple "monitor help" $test {
-re "The following monitor commands are supported.*debug-hw-points.*remote-debug.*GDBserver.*$gdb_prompt $" {
set is_gdbserver 1
pass $test
}
-re "$gdb_prompt $" {
set is_gdbserver 0
pass $test
}
}
if { $is_gdbserver == -1 } {
return -1
}
(and I have a TODO item about adding a "monitor version"
command, which would be better than "monitor help").
We could move that to a shared is_gdbserver procedure in lib/,
and then:
if is_gdbserver then expect $trace_timestamp, otherwise, fail
else expect $trace_timestamp, but be graceful if it isn't supported.
That's similar to what qtro.exp is doing.
--
Pedro Alves