From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46119 invoked by alias); 23 Mar 2016 17:25:59 -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 46070 invoked by uid 89); 23 Mar 2016 17:25:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=consultation 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; Wed, 23 Mar 2016 17:25:57 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id CCFDE64473; Wed, 23 Mar 2016 17:25:55 +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 u2NHPsrZ004994; Wed, 23 Mar 2016 13:25:55 -0400 Subject: Re: [PATCH 1/2] gdbarch software_single_step returns VEC (CORE_ADDR) * To: Yao Qi , gdb-patches@sourceware.org References: <1458742206-622-1-git-send-email-yao.qi@linaro.org> <1458742206-622-2-git-send-email-yao.qi@linaro.org> From: Pedro Alves Message-ID: <56F2D1A2.80103@redhat.com> Date: Wed, 23 Mar 2016 17:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1458742206-622-2-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00482.txt.bz2 On 03/23/2016 02:10 PM, Yao Qi wrote: > However, breakpoint insertion in arm is a little different, which > uses arm_insert_single_step_breakpoint, and it updates a global > variable arm_override_mode, so that arm_pc_is_thumb can get the > right arm thumb mode even the program is wrong (see > gdb.arch/thumb-singlestep.exp). I failed to remove global variable > arm_override_mode, so have to add a new gdbarch method > insert_single_step_breakpoint, which is in default > insert_single_step_breakpoint for all targets except arm. > I think the problem is the ambiguity in arm_breakpoint_from_pc, and to the fact that we don't "normalize" breakpoint addresses before passing them down to target_insert_breakpoint. Some callers start with an address coming from the user and want to consult symbol tables / mapping symbols. Other caller really want to trust the thumb bit as set in the address. Note that arm_breakpoint_from_pc uses arm_pc_is_thumb, which is what consults symbol tables / mapping symbols. I think the fix would to make arm_breakpoint_from_pc always trust that the address bit is already encoded correctly, and trust IS_THUMB_ADDR, similarly to how the gdbserver version does, in arm_breakpoint_kind_from_pc. Then, we'd still need to consult the mapping symbols consultation, or IOW, do something based on arm_pc_is_thumb _before_ target_insert_breakpoint is reached. That is, call something like arm_pc_is_thumb and use the result to encode the thumb bit correctly in the address passed to target_insert_breakpoint. IOW, "normalize" the target address, using some gdbarch method, _before_ that address is passed to the target routines in the first place. Along the way, several other functions would stop using arm_pc_is_thumb, but use IS_THUMB_ADDR directly. E.g., arm_remote_breakpoint_from_pc. WDYT? > -# A return value of 1 means that the software_single_step breakpoints > -# were inserted; 0 means they were not. > -F:int:software_single_step:struct frame_info *frame:frame > +# Return a vector of addresses on which the software single step > +# breakpoints are inserted. NULL means software single step is not used. s/are inserted/should be inserted/ > +F:VEC (CORE_ADDR) *:software_single_step:struct frame_info *frame:frame > + > +m:void:insert_single_step_breakpoint:struct address_space *aspace, CORE_ADDR pc:aspace, pc::insert_single_step_breakpoint::0 > > # Return non-zero if the processor is executing a delay slot and a > # further single-step is needed before the instruction finishes. > diff --git a/gdb/infrun.c b/gdb/infrun.c > index 696105d..5dbcf7a 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -2248,11 +2248,28 @@ maybe_software_singlestep (struct gdbarch *gdbarch, CORE_ADDR pc) > int hw_step = 1; > > if (execution_direction == EXEC_FORWARD > - && gdbarch_software_single_step_p (gdbarch) > - && gdbarch_software_single_step (gdbarch, get_current_frame ())) > + && gdbarch_software_single_step_p (gdbarch)) > { > - hw_step = 0; > + struct frame_info *frame = get_current_frame (); > + VEC (CORE_ADDR) * next_pcs; > + > + next_pcs = gdbarch_software_single_step (gdbarch, frame); > + > + if (next_pcs != NULL) > + { > + int i; > + CORE_ADDR pc; > + struct address_space *aspace = get_frame_address_space (frame); > + > + hw_step = 0; > + > + for (i = 0; VEC_iterate (CORE_ADDR, next_pcs, i, pc); i++) > + gdbarch_insert_single_step_breakpoint (gdbarch, aspace, pc); > + > + VEC_free (CORE_ADDR, next_pcs); > + } This pattern of starting from a VEC of addresses, and a frame and calling gdbarch_insert_single_step_breakpoint on each address appears multiple times. Can we put it in a convenience function? Though the other calls in record-full.c didn't go through gdbarch_insert_single_step_breakpoint -- why's that? Otherwise, this is fine with me. Thanks, Pedro Alves