From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13491 invoked by alias); 28 Jun 2009 10:16:40 -0000 Received: (qmail 13478 invoked by uid 22791); 28 Jun 2009 10:16:38 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 28 Jun 2009 10:16:32 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5SAGUGs018095 for ; Sun, 28 Jun 2009 06:16:30 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5SAGS2k031783; Sun, 28 Jun 2009 06:16:29 -0400 Received: from host0.dyn.jankratochvil.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5SAGQBu002514; Sun, 28 Jun 2009 06:16:28 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id n5SAGPg7011328; Sun, 28 Jun 2009 12:16:25 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id n5SAGLgA011316; Sun, 28 Jun 2009 12:16:21 +0200 Date: Sun, 28 Jun 2009 10:16:00 -0000 From: Jan Kratochvil To: gdb-patches@sourceware.org Cc: Mark Kettenis , Tom Tromey Subject: Re: [FYI] Inlining support, rough patch Message-ID: <20090628101621.GA31457@host0.dyn.jankratochvil.net> References: <20080715192020.GB3094@caradoc.them.org> <200807172353.m6HNr1nY015884@brahms.sibelius.xs4all.nl> <20080718130308.GA19045@caradoc.them.org> <200807251446.m6PEkfwc027635@brahms.sibelius.xs4all.nl> <20080725174636.GB2433@caradoc.them.org> <200903312042.n2VKgIUx003764@brahms.sibelius.xs4all.nl> <20090420154909.GA5386@caradoc.them.org> <20090420155405.GA6072@host0.dyn.jankratochvil.net> <20090627180122.GA6139@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090627180122.GA6139@caradoc.them.org> User-Agent: Mutt/1.5.19 (2009-01-05) 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-06/txt/msg00786.txt.bz2 On Sat, 27 Jun 2009 20:01:22 +0200, Daniel Jacobowitz wrote: > On Mon, Apr 20, 2009 at 05:54:05PM +0200, Jan Kratochvil wrote: > > Fedora also has various fixes on top of it: > > http://cvs.fedora.redhat.com/viewvc/rpms/gdb/devel/gdb-6.8-inlining-addon.patch?view=co ... > Others, particularly the testsuite changes, I don't understand. As I did not understand how the testsuites could work before - it is clear it was due to some compiler differences. I should retest the changes against FSF GCC first, my only concern was Fedora GCC for that patch. > current_pc_is_notcurrent is interesting. Do I have the scenario > right? Yes, thanks for checking it (the changed testcases cover it somewhere). > * function() calls inlined() calls other() > * finish from other() > * show the end of inlined() instead of the next line of function() > > I can't figure out if we should do this or not. It does seem useful. > But that's not where we are; we're showing the previous call site > instead of the next instruction. > > I think we should consider it as a general change for finish instead > of specific to inlining. The comments in your patch suggested that > too. My goal was to: (1) Keep non-inlined GDB behavior the same. (2) Keep the majority of inlined cases behavior the same as non-inlined one. For FSF GDB we should break the rule (1). (gdb) l 1 /* 1 */ int func (void) { return 1; } 2 /* 2 */ int main (void) { int x, y; 3 /* 3 */ func (); 4 /* 4 */ y = -1; 5 /* 5 */ x = func (); 6 /* 6 */ y = 1; 7 /* 7 */ return 0; } Temporary breakpoint 1, main () at finish.c:3 3 /* 3 */ func (); (gdb) step func () at finish.c:1 1 /* 1 */ int func (void) { return 1; } (gdb) finish Run till exit from #0 func () at finish.c:1 main () at finish.c:4 4 /* 4 */ y = -1; Value returned is $1 = 1 ### Here `finish' is at the _next_ line of the call. I would expect rather: ### (gdb) finish ### Run till exit from #0 func () at finish.c:1 ### main () at finish.c:4 ### 3 /* 3 */ func (); ### Value returned is $1 = 1 ### Whether this or that case is shown is also dependent on the current ### architecture - currently the behavior differs depending of whether there ### is at least one instruction of the same source line after the call ### instruction. Next `step' will have to do _nothing_ to the inferior, just ### display the next line in GDB. (gdb) step 5 /* 5 */ x = func (); (gdb) step func () at finish.c:1 1 /* 1 */ int func (void) { return 1; } (gdb) finish Run till exit from #0 func () at finish.c:1 0x00000000004004a0 in main () at finish.c:5 5 /* 5 */ x = func (); Value returned is $2 = 1 (gdb) step 6 /* 6 */ y = 1; (gdb) TODOlisted to submit a patch for this behavior change of non-inlined functions (which will cover even the inlined ones). Thanks for the merge, Jan