From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128640 invoked by alias); 16 Oct 2015 16:06:30 -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 128627 invoked by uid 89); 16 Oct 2015 16:06:30 -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,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, 16 Oct 2015 16:06:28 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id A303FA0B8C; Fri, 16 Oct 2015 16:06:27 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9GG6Pev000695; Fri, 16 Oct 2015 12:06:26 -0400 Message-ID: <56212081.5090703@redhat.com> Date: Fri, 16 Oct 2015 16:06:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Antoine Tremblay , gdb-patches@sourceware.org Subject: Re: [PATCH v2 4/7] Support breakpoint kinds for software breakpoints in GDBServer. References: <1444063455-31558-1-git-send-email-antoine.tremblay@ericsson.com> <1444063455-31558-5-git-send-email-antoine.tremblay@ericsson.com> <561FCB85.4020500@redhat.com> <561FEA3A.5020801@ericsson.com> In-Reply-To: <561FEA3A.5020801@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-10/txt/msg00287.txt.bz2 On 10/15/2015 07:02 PM, Antoine Tremblay wrote: > > > On 10/15/2015 11:51 AM, Pedro Alves wrote: >> On 10/05/2015 05:44 PM, Antoine Tremblay wrote: >>> This patch teaches GDBServer to: >>> >>> - choose the right breakpoint instruction for its own breakpoints, through API >>> set_breakpoint_at. >>> >>> - choose the right breakpoint instruction for breakpoints requested by GDB, >>> according to the information in Z packets, through API set_gdb_breakpoint. >>> >>> New fields are introduced in struct raw_breakpoint: >>> >>> pcfull: The PC including possible arch specific flags encoded in it. >> >> "full" as opposed to "empty"? Can we find a clearer term? >> > > full as opposed to incomplete, meaning it includes all it could include. > Other then that I would see : > > pcencoded ? > > pcflaged ? > > pcwithflags ? > > Not an easy one.. GDB calls them "placed address" and "requested address": struct bp_target_info { ... /* Address at which the breakpoint was placed. This is normally the same as REQUESTED_ADDRESS, except when adjustment happens in gdbarch_breakpoint_from_pc. The most common form of adjustment is stripping an alternate ISA marker from the PC which is used to determine the type of breakpoint to insert. */ CORE_ADDR placed_address; /* Address at which the breakpoint was requested. */ CORE_ADDR reqstd_address; > >>> @@ -100,6 +98,16 @@ struct raw_breakpoint >>> breakpoint for a given PC. */ >>> CORE_ADDR pc; >>> >>> + /* The breakpoint's insertion address, possibly with flags encoded in the pc >>> + (e.g. the instruction mode on ARM). */ >>> + CORE_ADDR pcfull; >>> + >>> + /* The breakpoint's data */ >>> + const unsigned char *data; >>> + >>> + /* The breakpoint's kind. */ >>> + int kind; >>> + >>> /* The breakpoint's size. */ >>> int size; >> >> Can't we always find the size from pcfull and kind ? >> > > We could but then we would have to call breakpoint_from_kind in a lot of > places basically everywhere bp->size is referenced like : > > check_mem_read > check_mem_write > insert_memory_breakpoint > remove_memory_breakpoint > set_raw_breakpoint_at > validate_inserted_breakpoint > delete_raw_breakpoint > uninsert_raw_breakpoint > reinsert_raw_breakpoint > find_raw_breakpoint_at See below. > > Also since these functions can be called in a stack one would have to be > careful to call breakpoint_from_kind at the right level and pass it > down.. and then size/kind becomes confusing. > > Also, this is a bit what I did in v1 but changed based on discussions > with Yao see : > > https://sourceware.org/ml/gdb-patches/2015-09/msg00597.html > > I think it's more clear to call the function once and set the variable. I don't see why my comment conflicts with Yao's. But I think we could simplify the interfaces and entry points, and get rid of the duplication, like this: Replace the breakpoint_from_pc method with a breakpoint_kind_from_pc method. This adjusts the PC (if necessary) and returns the breakpoint _kind_ instead of the breakpoint opcode / data. enum arm_breakpoint_kinds { ARM_BP_KIND_THUMB = 2, ARM_BP_KIND_THUMB2 = 3, ARM_BP_KIND_ARM = 4, }; static int arm_breakpoint_kind_from_pc (CORE_ADDR *pcptr, int len) { if (IS_THUMB_ADDR (*pcptr)) { gdb_byte buf[2]; *pcptr = UNMAKE_THUMB_ADDR (*pcptr); /* Check whether we are replacing a thumb2 32-bit instruction. */ if ((*the_target->read_memory) (*pcptr, buf, 2) == 0) { unsigned short inst1 = 0; (*the_target->read_memory) (*pcptr, (gdb_byte *) &inst1, 2); if (thumb_insn_size (inst1) == 4) return ARM_BP_KIND_THUMB2; } return ARM_BP_KIND_THUMB; } else return ARM_BP_KIND_ARM; } Then the breakpoints functions and structures always work with the already-adjusted PC, and with a breakpoint-kind. for internal breakpoints, we have: set_breakpoint_at (breakpoint_kind_from_pc, to find bp kind, rest the same as today) set_gdb_breakpoint_1 (same as today) | `--> set_breakpoint (address, kind) | `-->set_raw_breakpoint_at (address, kind) | `--> the_target->insert_point (address, kind) Everything thinks in terms of breakpoint kind. Then the only places that need to know the real breakpoint instruction opcode and opcode size can query the breakpoint_from_kind target method you already added. About: > We could but then we would have to call breakpoint_from_kind in a lot of > places basically everywhere bp->size is referenced like : > > check_mem_read > check_mem_write > insert_memory_breakpoint > remove_memory_breakpoint > set_raw_breakpoint_at > validate_inserted_breakpoint > delete_raw_breakpoint > uninsert_raw_breakpoint > reinsert_raw_breakpoint > find_raw_breakpoint_at Minimizing the patch size is less important than making sure the resulting code is clear Sounds like that's manageable with a trivial replace of bp->size with a call to something like: static int bp_size (struct raw_breakpoint *bp) { int size = bp->kind; breakpoint_from_kind (&size); return size; } Likewise for the opcode data: static const gdb_byte * bp_opcode (struct raw_breakpoint *bp) { int size = bp->kind; return breakpoint_from_kind (&size); } Doesn't seem to me like the end result would be any less clear. Thanks, Pedro Alves