From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4857 invoked by alias); 19 May 2009 20:21:25 -0000 Received: (qmail 4848 invoked by uid 22791); 19 May 2009 20:21:24 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 May 2009 20:21:15 +0000 Received: (qmail 772 invoked from network); 19 May 2009 20:21:13 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 May 2009 20:21:13 -0000 From: Pedro Alves To: Ross Morley Subject: Re: [Fwd: Re: [PATCH] Program Breakpoints] Date: Tue, 19 May 2009 20:21:00 -0000 User-Agent: KMail/1.9.10 Cc: "gdb-patches@sourceware.org" References: <4A12EC43.3010107@tensilica.com> <200905191958.35348.pedro@codesourcery.com> <4A130DE1.9060202@tensilica.com> In-Reply-To: <4A130DE1.9060202@tensilica.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905192121.10299.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2009-05/txt/msg00405.txt.bz2 On Tuesday 19 May 2009 20:52:01, Ross Morley wrote: > Thanks Pedro. This is the kind of feedback I was looking for > in regard to effects on threads and other archs. I will have > to go through your comments and think about those scenarios > you mentioned with stepping. Before I do that I do want to > clarify a couple of things for you. > > First, the intention is that a program breakpoint is not > reported in the case of hitting a GDB breakpoint. You mean, reported to the user, right? I agree. However, the target will report to gdb a program breakpoint for gdb breakpoints as well: + if (the_low_target.trap_size_at != NULL) + trap_size = (*the_low_target.trap_size_at) (stop_pc); + else if (the_low_target.breakpoint_at != NULL + && (*the_low_target.breakpoint_at) (stop_pc)) + trap_size = the_low_target.breakpoint_len; Only way to tell the difference is if there's a breakpoint at PC in gdb's tables or not. Hmm, isn't there an off-by-one error in the XCHAL_HAVE_BE case here? : +#if XCHAL_HAVE_BE + if (insn[1] == 0xd2 && (insn[2] & 0x0f) == 0x0f) +#else + if (insn[0] == 0x2d && (insn[1] & 0xf0) == 0xf0) +#endif + /* break.n s (density) */ > Test cases seem impossible to write completely generically > because the test needs a target-specific break instruction. > We have one (not in this patch) I could submit for Xtensa. > It places 2 sizes of program breakpoints for Xtensa as follows: > __asm__("break 7,15"); > __asm__("break.n 7"); > Is there a way to write a generic test with a program break? I think you can do something reasonably generic enough by passing "additional_flags=-DNOP=mysmallnopinsn -DBREAK_INSN1=foo -DBREAK_INSN2=bar" to gdb_compile, and write the test in c with embedded asm, as: int foo () { NOP NOP BREAK_INSN1 jmphere: NOP /* breakpoint here*/ NOP BREAK_INSN1 NOP goto jmphere; } etc, etc. Then, the .exp file passes the appropriate defines/flags based on target triplet. if { ([istarget "xtensa*-*-*"] } { additional_flags={-DNOP=mysmallnopinsn -DBREAK_INSN1="break 7,15" -DBREAK_INSN2="break.n 7"} } else if { ([istarget "fooarch*-*-*"] } { ... } -- Pedro Alves