From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89164 invoked by alias); 2 May 2016 10:21:10 -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 89152 invoked by uid 89); 2 May 2016 10:21:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=hmm, Hx-languages-length:1692 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; Mon, 02 May 2016 10:21:07 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BBE6A81105; Mon, 2 May 2016 10:21:06 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u42AL50W018193; Mon, 2 May 2016 06:21:06 -0400 Subject: Re: [PATCH 1/2] gdbarch software_single_step returns VEC (CORE_ADDR) * To: Yao Qi References: <1458742206-622-1-git-send-email-yao.qi@linaro.org> <1458742206-622-2-git-send-email-yao.qi@linaro.org> <56F2D1A2.80103@redhat.com> <86egasrr2a.fsf@gmail.com> <86d1p8eajb.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Mon, 02 May 2016 10:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <86d1p8eajb.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-05/txt/msg00002.txt.bz2 On 04/29/2016 03:48 PM, Yao Qi wrote: > >> > So when setting a single-step breakpoint, we'd get the "kind" >> > from the current mode, and when setting breakpoints from >> > user-input, we'd get it from the symbols tables / mapping symbols. > This means we need this to get the "kind" from the current mode, > > /* Return the breakpoint kind for this target based on the current > processor state (e.g. the current instruction mode on ARM) and the > PC. The PCPTR is adjusted to the real memory location in case a flag > (e.g., the Thumb bit on ARM) is present in the PC. */ > int (*breakpoint_kind_from_current_state) (CORE_ADDR *pcptr); Hmm, not sure, maybe. From the perspective of syncing design with gdbserver, it makes sense. On gdbserver, I think that's only used for advancing past a permanent breakpoint. On gdb side, we use gdbarch_skip_permanent_breakpoint, which I think no arch overrides currently, so it always ends up in default_skip_permanent_breakpoint -> gdbarch_breakpoint_from_pc. (Looks like we could eliminate gdbarch_skip_permanent_breakpoint.) We could also say we should keep gdb's permanent breakpoint skipping's logic of determining which breakpoint instruction to skip in sync with bp_loc_is_permanent -> program_breakpoint_here_p -> gdbarch_breakpoint_from_pc, though in this case looking at the current mode doesn't make sense. > > and also need to pass breakpoint location to to_insert_breakpoint to get > the type of breakpoint we are inserting, right? I was thinking we'd have all we need in bp_target_info->placed_size, but of course I may be missing something. Thanks, Pedro Alves