From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26000 invoked by alias); 8 Feb 2012 08:39:56 -0000 Received: (qmail 25988 invoked by uid 22791); 8 Feb 2012 08:39:54 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Feb 2012 08:39:39 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Rv33z-0004Ug-Aq from Hui_Zhu@mentor.com for gdb-patches@sourceware.org; Wed, 08 Feb 2012 00:39:39 -0800 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 00:39:39 -0800 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Wed, 8 Feb 2012 00:39:37 -0800 Message-ID: <4F3234C6.7020104@mentor.com> Date: Wed, 08 Feb 2012 08:39:00 -0000 From: Hui Zhu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Subject: Re: [PATCH] Fix error when gdb connect to a stub that tracepoint is running[1/2] reset current_trace_status in the begin of remote_start_remote References: <4F274C42.7010008@mentor.com> In-Reply-To: <4F274C42.7010008@mentor.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2012-02/txt/msg00095.txt.bz2 Ping. Thanks, Hui On 01/31/12 10:04, Hui Zhu wrote: > Hi, > > For the re-insert breakpoint, the stack dump is: > #0 remote_download_tracepoint (loc=0x35040b0) at > ../../src/gdb/remote.c:9982 > #1 0x00000000006727c1 in download_tracepoint_locations () at > ../../src/gdb/breakpoint.c:10670 > #2 0x0000000000673111 in update_global_location_list (should_insert=1) > at ../../src/gdb/breakpoint.c:11021 > #3 0x0000000000663752 in create_overlay_event_breakpoint () at > ../../src/gdb/breakpoint.c:2322 > #4 0x0000000000675c9f in breakpoint_re_set () at > ../../src/gdb/breakpoint.c:12621 > #5 0x00000000007efe65 in solib_add (pattern=0x0, from_tty=1, > target=0x1d1e860, readsyms=1) > at ../../src/gdb/solib.c:928 > #6 0x000000000057b452 in enable_break (info=0x3307890, from_tty=1) at > ../../src/gdb/solib-svr4.c:1624 > #7 0x000000000057c428 in svr4_solib_create_inferior_hook (from_tty=1) at > ../../src/gdb/solib-svr4.c:2234 > #8 0x00000000007f04a9 in solib_create_inferior_hook (from_tty=1) at > ../../src/gdb/solib.c:1172 > #9 0x00000000006cc8e5 in post_create_inferior (target=0x1d1e860, > from_tty=1) at ../../src/gdb/infcmd.c:431 > #10 0x00000000006d479d in start_remote (from_tty=1) at > ../../src/gdb/infrun.c:2309 > #11 0x00000000005d80c9 in remote_start_remote (from_tty=1, > target=0x1cefce0, extended_p=0) > at ../../src/gdb/remote.c:3367 > > About this patch, what I do is: > 1. If we try to connect an new stub, reset current_trace_status to unknown. > 2. Change remote_can_download_tracepoint to if the current_trace_status > is unknown, return false. > After this patch, the tracepoint insered after: > /* Possibly the target has been engaged in a trace run started > previously; find out where things are at. */ > if (remote_get_trace_status (current_trace_status ()) != -1) > { > I think that will make us handle tracepoint issue more easy. > > 2012-01-31 Hui Zhu > > * remote.c (remote_start_remote): Set running_known of > current_trace_status to 0 in the begin of this function. > (remote_can_download_tracepoint): If running_known of > current_trace_status is 0, return false. > > Thanks, > Hui