Re: [PATCH] Upload TSVs in extend-remote mode

[Pedro Alves <palves@redhat.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