From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28710 invoked by alias); 20 Jun 2013 18:34:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 28685 invoked by uid 89); 20 Jun 2013 18:34:55 -0000 X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 20 Jun 2013 18:34:55 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5KIYqPs010642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 14:34:52 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r5KIYpxQ002499; Thu, 20 Jun 2013 14:34:51 -0400 Message-ID: <51C34B4A.7000606@redhat.com> Date: Thu, 20 Jun 2013 18:36:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Upload TSVs in extend-remote mode References: <1371636174-9822-1-git-send-email-yao@codesourcery.com> In-Reply-To: <1371636174-9822-1-git-send-email-yao@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00557.txt.bz2 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