From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32150 invoked by alias); 8 May 2015 12:29:36 -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 32138 invoked by uid 89); 8 May 2015 12:29:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 08 May 2015 12:29:34 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t48CTSTp003704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 8 May 2015 08:29:28 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t48CTQgq010193; Fri, 8 May 2015 08:29:27 -0400 Message-ID: <554CAC25.5090909@redhat.com> Date: Fri, 08 May 2015 12:29:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Antoine Tremblay , Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets References: <1430411029-12097-1-git-send-email-qiyaoltc@gmail.com> <554A368F.4060309@redhat.com> <86oalwvf38.fsf@gmail.com> <554B5052.2090904@ericsson.com> <554CA308.1030509@redhat.com> <554CA83F.7080909@ericsson.com> In-Reply-To: <554CA83F.7080909@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00189.txt.bz2 On 05/08/2015 01:12 PM, Antoine Tremblay wrote: > This looks very nice thanks! , but I do have one question , why is the > result a VEC ? > > From the context and current code won't we have only one next instruction ? Nope. Most frequent case is conditional branches where we don't know where the program will end up. Might be the destination of the branch, if the instruction evals true, or after the branch, if the condition evals false. Even though the arm code manages to evaluate most conditions itself upfront, there are still some cases where it can't. The way we handle it currently is that the get_next_pc functions call insert extra single-step breakpoints themselves, like e.g., in thumb_get_next_pc_raw: else { int cond_negated; /* There are conditional instructions after this one. If this instruction modifies the flags, then we can not predict what the next executed instruction will be. Fortunately, this instruction is architecturally forbidden to branch; we know it will fall through. Start by skipping past it. */ pc += thumb_insn_size (inst1); itstate = thumb_advance_itstate (itstate); /* Set a breakpoint on the following instruction. */ gdb_assert ((itstate & 0x0f) != 0); arm_insert_single_step_breakpoint (gdbarch, aspace, MAKE_THUMB_ADDR (pc)); cond_negated = (itstate >> 4) & 1; So you see how this is a misleading/surprising interface, naturally something that grew organically instead of being designed for multiple potential destinations. Another case where the ARM code (and others like PPC) need more than one "next pc" is when dealing with atomic sequences. See e.g., arm_deal_with_atomic_sequence_raw. gdbserver needs all that atomic sequence code too. > > Also, if you may,file structure wise, where would be a good place for > this abstration layer in your view ? Good question. Maybe a new gdb/arch/ directory. But I'd be fine with putting it in gdb/common/ for now. Thanks, Pedro Alves