From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16781 invoked by alias); 14 Nov 2002 03:44:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16773 invoked from network); 14 Nov 2002 03:44:14 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 14 Nov 2002 03:44:14 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 013543E4B; Wed, 13 Nov 2002 22:44:13 -0500 (EST) Message-ID: <3DD31C0D.4050207@redhat.com> Date: Wed, 13 Nov 2002 19:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Donn Terry Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: Single step vs. "tail recursion" optimization References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00407.txt.bz2 > (I'm sorry to have to be the messenger on this one...) > > Here's a mini testcase. I've also attached the resulting .s files for > -O2 and -O3. > Shudder. Andrew's speculation about s not working because there were no > symbols > is correct. S-ing works until the call to getpid(). > > I haven't actually tried to figure out why gdb isn't doing it right in > that case > because there's actually something potentially even uglier going on in > the -O3 case. > This is something that the "management" of gdb and the "management" of > gcc are going > to have to take on and resolve as either "no, you can't sanely debug > -O3" or "we need > some help from the compiler to sort this one out". (And if the latter, > then the same > help may be useful with the -O2 case!) (I haven't seen this addressed, > but I could > easily have missed it.) GDB's going to have to learn to do something with -O3, even if it isn't very sane :-) > Note that in the case of -O3, foo() and bar() are NEVER actually called > from main, > but rather getpid() is called directly. (Note also the reordering of the > functions.) > (Seeing that this sort of optimization is pretty compellingly needed for > C++ code, > "don't do that" seems an unlikely outcome.) Anyway, here's a wild guess: - gdb stepi's into getpid() (or what ever the tail recursive function is) - detects this because its no longer in foo() - gdb calls saved_pc_after_call() and gets an address in main, sets tempoary breakpoint at that address. I think, if this isn't happening, GCC will have by definition, screwed up the stack frame. The stack, for getpid() and hence GDB, has to appear like it was called from main() so getpid() will correctly return there. - gdb resumes target - getpid() returns, hits breakpoint in main, but the logic there (hmm, Elena's `until' post) doesn't realise that its exited the function / block in question. - gdb resumes target, target exits I think you can see this by either setting a breakpoint on saved_pc_after_call() or by watching the target traffic (set debug target 1?). Andrew