From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19298 invoked by alias); 27 Sep 2011 10:44:41 -0000 Received: (qmail 19290 invoked by uid 22791); 27 Sep 2011 10:44:40 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,FROM_12LTRDOM X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Sep 2011 10:44:21 +0000 Received: from nat-jpt.mentorg.com ([192.94.33.2] helo=PR1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1R8V9B-0001fH-3a from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Tue, 27 Sep 2011 03:44:21 -0700 Received: from [172.30.112.173] ([172.30.112.173]) by PR1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Sep 2011 19:44:20 +0900 Message-ID: <4E81A8FC.3070905@codesourcery.com> Date: Tue, 27 Sep 2011 12:53:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: [ping]: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703) References: <000001cc3216$b96ba290$2c42e7b0$@guo@arm.com> <4E040A9A.5020807@codesourcery.com> <201106240959.08358.pedro@codesourcery.com> <4E04692F.3030500@codesourcery.com> In-Reply-To: <4E04692F.3030500@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-09/txt/msg00456.txt.bz2 On 06/24/2011 06:38 PM, Yao Qi wrote: >> > 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 ) >> > > thumb_instruction_changes_pc can handle "b.n". AFAICS, the problem is > in thumb_analyze_prologue. In thumb_analyze_prologue, there are a lot > if/else branches, like below, > > else if ((insn & 0xe000) == 0xe000) // <-- [1] > { > .... > else if (thumb2_instruction_changes_pc (insn, inst2)) > { > /* Don't scan past anything that might change control flow. */ > break; > } > else > { > /* The optimizer might shove anything into the prologue, > so we just skip what we don't recognize. */ > unrecognized_pc = start; > } > > start += 2; > } > else if (thumb_instruction_changes_pc (insn)) > { > /* Don't scan past anything that might change control flow. */ > break; > } > > The instruction "b.n 8160" is 0xe7fe, so condition check [1] is true, > and thumb_instruction_changes_pc is unreachable. This is cause of this > problem, I doubt. > > > The line of code [1] is discussed in this patch > > [rfa] ARM prologue parsing support for Thumb-2 instructions > http://sourceware.org/ml/gdb-patches/2010-10/msg00132.html > > IIUC, condition check [1] is for 32-bit Thumb-2 instructions (I may be > wrong, of course). I have an untested patch. > When talking with Terry Guo on HelloGCC workshop last Saturday in Beijing, it reminds me that I still have a patch pending there, and forget to ping it. http://sourceware.org/ml/gdb-patches/2011-06/msg00370.html I regression tested this patch on armv7l-unknown-linux-gnueabi with {-mthumb, -marm}, no new fails. OK for mainline? > gdb/ > * arm-tdep.c (thumb_analyze_prologue): Check condition for 32-bit > Thumb-2 instructions. > > diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c > index 2dd8c9e..7f5a0e1 100644 > --- a/gdb/arm-tdep.c > +++ b/gdb/arm-tdep.c > @@ -832,8 +832,9 @@ thumb_analyze_prologue (struct gdbarch *gdbarch, > constant = read_memory_unsigned_integer (loc, 4, byte_order); > regs[bits (insn, 8, 10)] = pv_constant (constant); > } > - else if ((insn & 0xe000) == 0xe000) > + else if ((insn & 0xe000) == 0xe000 && (insn & 0x1800) != 0) > { > + /* 32-bit Thumb-2 instructions. */ > unsigned short inst2; > > inst2 = read_memory_unsigned_integer (start + 2, 2, -- Yao (齐尧)