From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117021 invoked by alias); 24 Sep 2015 16:43:16 -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 117008 invoked by uid 89); 24 Sep 2015 16:43:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: usevmg21.ericsson.net Received: from usevmg21.ericsson.net (HELO usevmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 24 Sep 2015 16:43:14 +0000 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 62.0D.26730.9CCB3065; Thu, 24 Sep 2015 11:05:13 +0200 (CEST) Received: from [142.133.110.95] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.89) with Microsoft SMTP Server id 14.3.248.2; Thu, 24 Sep 2015 12:43:11 -0400 From: Antoine Tremblay Subject: Re: [pushed] gdbserver: redo stepping over breakpoint that was on top of a permanent breakpoint To: Yao Qi References: <1424723261-15719-1-git-send-email-palves@redhat.com> <861tdo9jy6.fsf@gmail.com> <5603E0F7.10205@ericsson.com> <86wpvg7y22.fsf@gmail.com> CC: Message-ID: <5604281F.6010203@ericsson.com> Date: Thu, 24 Sep 2015 16:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <86wpvg7y22.fsf@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00561.txt.bz2 On 09/24/2015 09:21 AM, Yao Qi wrote: > Antoine Tremblay writes: > >> Indeed I have a fix for this see : >> https://sourceware.org/ml/gdb-patches/2015-09/msg00222.html >> > > Ah, I did read your patch, but I forget it when I am fixing this problem. > Np, I think that patch is valid with the scenario you mention below, however since it won't work properly as reinsert_addr doesn't work at this stage I think it may be better to introduce it when I post the single stepping support ? > It can be triggered when GDBserver steps over its breakpoints, what I > did is to pass 1 to thread_db_init, so that GDBserver will insert > breakpoint on __nptl_create_event. Once a new thread is created, and > hits this breakpoint, GDBserver will step over this breakpoint. > Haa I had missed that scenario! >--- a/gdb/gdbserver/linux-low.c +++ b/gdb/gdbserver/linux-low.c @@ -3010,7 +3010,8 @@ linux_wait_1 (ptid_t ptid, Advance the PC manually past the breakpoint, otherwise the program would keep trapping the permanent breakpoint forever. */ if (!ptid_equal (step_over_bkpt, null_ptid) - && event_child->stop_reason == TARGET_STOPPED_BY_SW_BREAKPOINT) + && event_child->stop_reason == TARGET_STOPPED_BY_SW_BREAKPOINT + && gdb_breakpoint_here (event_child->stop_pc)) { int increment_pc = 0; CORE_ADDR stop_pc = event_child->stop_pc; This won't work as that single step breakpoint is not a gdb breakpoint we need to check for a reinsert breakpoint like the patch I mentioned. I tested the scenario with my patch and the issue is solved. Note however I'm a bit concerted about the hack to remote_check_symbols. I need to dig into it to understand that one should we expect it to work without this hack ?