From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23670 invoked by alias); 29 Jun 2011 05:36:06 -0000 Received: (qmail 23524 invoked by uid 22791); 29 Jun 2011 05:36:05 -0000 X-SWARE-Spam-Status: No, hits=-1.8 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; Wed, 29 Jun 2011 05:35:51 +0000 Received: (qmail 8628 invoked from network); 29 Jun 2011 05:35:50 -0000 Received: from unknown (HELO ?192.168.0.101?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Jun 2011 05:35:50 -0000 Message-ID: <4E0AB9B3.8060104@codesourcery.com> Date: Wed, 29 Jun 2011 05:36:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Terry Guo CC: gdb-patches@sourceware.org, pedro@codesourcery.com Subject: Re: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703) References: <000901cc34bc$fd1aa6a0$f74ff3e0$@guo@arm.com> <000101cc35fb$8d45ff60$a7d1fe20$@guo@arm.com> In-Reply-To: <000101cc35fb$8d45ff60$a7d1fe20$@guo@arm.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-06/txt/msg00435.txt.bz2 On 06/29/2011 09:26 AM, Terry Guo wrote: > Hi, > > I slightly modified the test case and got the below code: > > 00008142 : > 8142: 250a movs r5, #10 > Could you show the source code of function "test"? I can't figure out how gcc generates such code. Is it optimized by tail-call optimization? > > Without Yao's patch, the "b bar" sets the break point at 0x8158. With Yao's > patch, the "b test" still sets the break point at 0x814e that is outside the > function test body. But the "b bar" sets the break point at 0x814e which is > better than 0x8158. IMHO, theoretically function test could have many other > different kinds of instruction patterns. So I think it is better to have two There are many patterns of prologue, and that is why arm/thumb prologue analyzer has long if/else statements to handle different cases. My understanding is, if GCC emit some prologue that GDB's prologue analyzer doesn't understand, we have to improve prologue analyzer. > enhancements one is Yao's patch which enhances the function > thumb_analyze_prologue and make it more accurate, and another one is my > patch which ensures the function break point to be always set inside the > function body in a more general way. Does this solution sound good? I am not against your approach, but prologue analyzer is still unable to analyze some corner-case functions, so I am afraid stack backtrace on these corner-case functions doesn't work, because stack bactrace need the information provided from prologue analyzer. In short, we should improve prologue analyzer to understand such prologue as much as we can. If it is difficult to understand some strange prologue, such as your case, we have to resort to your patch. -- Yao (齐尧)