From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10905 invoked by alias); 13 Nov 2002 17:52:53 -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 10873 invoked from network); 13 Nov 2002 17:52:53 -0000 Received: from unknown (HELO mail5.microsoft.com) (131.107.3.121) by sources.redhat.com with SMTP; 13 Nov 2002 17:52:53 -0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 13 Nov 2002 09:52:52 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 13 Nov 2002 09:52:52 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 13 Nov 2002 09:52:52 -0800 Received: from red-msg-08.redmond.corp.microsoft.com ([157.54.12.5]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 13 Nov 2002 09:52:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Single step vs. "tail recursion" optimization Date: Wed, 13 Nov 2002 09:52:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Donn Terry" To: "Jim Blandy" Cc: "Michael Snyder" , X-OriginalArrivalTime: 13 Nov 2002 17:52:51.0768 (UTC) FILETIME=[7C7DCB80:01C28B3D] X-SW-Source: 2002-11/txt/msg00370.txt.bz2 No, it doesn't. In the original case (debugging gdb itself) it was down a lot of levels (of debuggable code, just the function being tail-called wasn't debuggable). It doesn't work (runs away) in the testcase either. I haven't tried to figure out what it thinks it is doing under those circumstances, being busy putting out other fires. I understand that you can't expect debugging to work completely as you expect in the face of this sort of optimization, but running away has some potentially really nasty consequences, so it would be nice to find a way to prevent that. I don't have access to implementations other than Inteix at the moment. Is this something specific to Interix, to x86's, or is it general? (I could easily imagine any of the above.) The small testcase I sent the other day should detect that easily enough. Donn -----Original Message----- From: Jim Blandy [mailto:jimb@redhat.com]=20 Sent: Wednesday, November 13, 2002 9:28 AM To: Donn Terry Cc: Michael Snyder; gdb-patches@sources.redhat.com Subject: Re: Single step vs. "tail recursion" optimization Michael Snyder writes: > Donn Terry wrote: > >=20 > > (I'm sorry to have to be the messenger on this one...) > >=20 > > Here's a mini testcase. I've also attached the resulting .s files=20 > > for -O2 and -O3. >=20 > You do know, don't you, that there are lots of optimizations that GDB=20 > fails to debug at -O2 and -O3? If something bad happens at those=20 > levels, our practice is to say "turn down the optimization and try=20 > again". Yeah, in general there's no way for GDB to produce the expected backtrace when the compiler has turned a call in tail position into a pop-frame-and-jump. There's simply no record at all of the function that made the tail call on the stack. But when there's a tail call to a function with no debug info, it seems to me that GDB should still do better than just letting the program run away. When "step" or "next" notice that they've stepped into a new function which has no debug info, they're supposed to set a breakpoint at the return address and run until that's hit. Now, in the presence of tail call optimizations, that return address is going to be one (or more) stack frames further back than you expect, but it should still get hit eventually. In your program, that breakpoint should be set in main, I think. Doesn't that work?