From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110650 invoked by alias); 31 Mar 2017 16:31:42 -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 110639 invoked by uid 89); 31 Mar 2017 16:31:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2569 X-HELO: mail-wr0-f182.google.com Received: from mail-wr0-f182.google.com (HELO mail-wr0-f182.google.com) (209.85.128.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Mar 2017 16:31:40 +0000 Received: by mail-wr0-f182.google.com with SMTP id w43so110518970wrb.0 for ; Fri, 31 Mar 2017 09:31:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=zw9WqevNlFM1HPSFEyBxAouKnGgMY+vlSW7VMl8SG0Y=; b=aZTNgOlMd60m3ZQi/Y5qA8Z8yjHBHEZTIW+2vBS+RubkLiI4s2pcuPmIT98Ei6PezP oIsgUIocREKDV3brc6kWzoabLARNikWB4FrXkk/ZAt3vpusL6b85KOwRS1GToMjrVgs7 5xlqJWtUmxO18TDFDZy/gAv1PGWxlFNC4tEwWT6Gg+ADHnOvC/XX5NwsMgmj7zxaW+Na vOZNES3p1PXAV5v/UQaQ0zKIkqTQiRj9fbMc0/7P0My8HklUXN3KKD9hbwlqFZMA4LbM SXCe0ri0p4I+yZJoFjFFryUhbPX7jDnu/F8bakwGx0PkYi7bOpKzgNN4rzOePg5VbF7R rvtw== X-Gm-Message-State: AFeK/H0WwVcojH25tTLhRY2xR0mOmuCRtCQPK4dPjQd0WceHh+/+4uXQOPpsYJw1Me7Qng== X-Received: by 10.223.176.133 with SMTP id i5mr4021475wra.97.1490977899973; Fri, 31 Mar 2017 09:31:39 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id m186sm3476119wmd.21.2017.03.31.09.31.38 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 31 Mar 2017 09:31:39 -0700 (PDT) From: Yao Qi To: Antoine Tremblay Cc: Pedro Alves , "gdb-patches\@sourceware.org" Subject: Re: [PATCH 1/2] This patch fixes GDBServer's run control for single stepping References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> <20170127150139.GB24676@E107787-LIN> <2255ed6f-a146-026c-f871-00e9a33dfcf0@redhat.com> <86d1cy4umo.fsf@gmail.com> Date: Fri, 31 Mar 2017 16:31:00 -0000 In-Reply-To: (Antoine Tremblay's message of "Thu, 30 Mar 2017 14:31:26 -0400") Message-ID: <86d1cxwgpk.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00548.txt.bz2 Antoine Tremblay writes: > You have to add if the current instruction is an IT instruction in wich > case the next instruction will be in an IT block. > Oh, you are right. > Also if you have a conditional instruction that would evalutate to > true and is not the last one, get_next_pcs may return an instruction > after the IT block, arm_breakpoint_kind_from_current_state will be > called from the IT block with that PC and return a THUMB2_KIND when it > should not. See the else case in arm-get-next-pcs.c:~351 With the current PC and CPSR, it is not difficult to know whether next_pc is still within IT block nor not, because all instructions in IT block should be sequentially executed or skipped. > > My point was that we should use get_next_pc directly since it's the best > place to detect if the next_pc is in the IT block. And the intent would > be clear. Yeah, we can record the information of breakpoint type in the return value of get_next_pc, ... > > It would give something like the patch below. (Note the GDB part of this > is missing but it works with GDBServer) > ... but using extra bit in CORE_ADDR is not a good idea to me. >> The problem of this patch is that we end up inserting different >> kinds of breakpoints on the same instruction. For a given 32-bit thumb >> instruction, GDB and GDBserver knows 32-bit thumb breakpoint instruction >> is used for GDB breakpoint, but only GDBserver knows 16-bit thumb >> breakpoint is used for GDBserver single-step breakpoint, so GDB will be >> confused on this. I stopped here, and start to do something else. > > Humm but how will the GDBServer 16-bit breakpoint be reported to GDB ? > Won't it always be hit and handled by GDBServer ? > > And if you have a GDB breakpoint on an instruction and GDBServer puts > a single step breakpoint on that GDB breakpoint instruction, GDBServer > still knows of the GDB and GDBServer breakpoint types. > > So how does GDB get confused ? That was my conclusion at that point. I got some regressions in gdb.threads/*.exp when I tested my patch (gdb running is on x86_64-linux), but I can't remember more details. I am also wondering that we can use some code in arm_adjust_breakpoint_address about detecting BPADDR is within IT block or not by scanning instructions backward, if none of two bytes (can be 16-bit thumb instruction or the 2nd half of 32-bit thumb instruction) matches IT instruction, the PC is not within IT block. --=20 Yao (=E9=BD=90=E5=B0=A7)