From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14085 invoked by alias); 24 Jun 2011 08:59:26 -0000 Received: (qmail 14075 invoked by uid 22791); 24 Jun 2011 08:59:25 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Jun 2011 08:59:12 +0000 Received: (qmail 24630 invoked from network); 24 Jun 2011 08:59:11 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Jun 2011 08:59:11 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703) Date: Fri, 24 Jun 2011 08:59:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) Cc: Yao Qi References: <000001cc3216$b96ba290$2c42e7b0$@guo@arm.com> <4E040A9A.5020807@codesourcery.com> In-Reply-To: <4E040A9A.5020807@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201106240959.08358.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: 2011-06/txt/msg00369.txt.bz2 On Friday 24 June 2011 04:55:06, Yao Qi wrote: > On 06/24/2011 10:30 AM, Terry Guo wrote: > > IMO, this is a target-specific bug, so this PR's component should be > tdept, so it should be "PR tdept/12703" instead of "PR gdb/12703". > > I'd move your test cases break-function.{c,exp} to gdb.arch/ dir, > because it is target-dependent fix. I am sure this case is useful to > other ports. The testcase might help catch the same issue in other archs. IMO, it should stay generic if possible. I agree with Yao when he says in the PR that there seems to be some other root cause for the bug. Shouldn't thumb_instruction_changes_pc have caught that "b.n" ? 00008160 : 8160: e7fe b.n 8160 ... 00008164 : 8164: 4a05 ldr r2, [pc, #20] ; (817c ) > > +void foo(void) > > This doesn't comply to GNU coding standard. Please move "foo ()" to > next line. Note that test code does not strictly _need_ to follow the coding standards. Though it's indeed nice when it does. GDB should be able to debug non-GNU code too. :-) -- Pedro Alves