From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16655 invoked by alias); 1 Jul 2011 09:47:06 -0000 Received: (qmail 16639 invoked by uid 22791); 1 Jul 2011 09:47:05 -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, 01 Jul 2011 09:46:43 +0000 Received: (qmail 2600 invoked from network); 1 Jul 2011 09:46:42 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Jul 2011 09:46:42 -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, 01 Jul 2011 09:47:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) Cc: Richard Earnshaw , Yao Qi , Terry Guo References: <000901cc34bc$fd1aa6a0$f74ff3e0$@guo@arm.com> <4E0AF7A6.1040800@codesourcery.com> <4E0D8C5B.2090407@arm.com> In-Reply-To: <4E0D8C5B.2090407@arm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201107011046.36650.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-07/txt/msg00006.txt.bz2 On Friday 01 July 2011 09:59:07, Richard Earnshaw wrote: > On 29/06/11 11:00, Yao Qi wrote: > > On 06/29/2011 04:47 PM, Terry Guo wrote: > >> Hi, > >> > >> First if you look at the generated binary code, I thought it is a valid case. After performing the function test, it will fall into function bar which is a normal function. At least my case can run correctly on QEMU. It is very likely for people to write program in assembly code like: > >> > >> main: > >> b test > >> > >> test: > >> movs r5, #10 > >> bar: > >> push....... > >> ......... > >> > > > > We are lucky here GCC places bar next to function test physically, but > > gcc may also place function test and bar in other layout, like > > > > main: > > b test > > > > bar: > > push ... > > > > test: > > moves r5, #10 > > > > After test, processor will run some instructions that we don't know. > > IMO, it is incorrect. > > > > Which is one of the reasons why GCC has the option -fno-toplevel-reorder > to prevent such reordering. Indeed. Well, GDB is not a compiler; it is supposed to be able to debug buggy code. :-) Turning things upside down, the root question is whether there are valid cases where when setting a breakpoint at "foo", when GDB goes analysing the prologue, GDB should cross function boundaries into the next function, which would get broken by Terry's proposal. E.g., say, foo and bar get merged by some smart compiler/linker: foo: bar: I guess setting a break on "foo" should set a breakpoint on "". Or (another user of prologue skipping,) stepping into a foo() call should only stop on "". Or, should GDB be conservative, and never cross the function body when skipping the prologue the hard way, and only cross it if debug info says so. -- Pedro Alves