From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22424 invoked by alias); 9 Oct 2007 21:03:48 -0000 Received: (qmail 22386 invoked by uid 22791); 9 Oct 2007 21:03:47 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Oct 2007 21:03:45 +0000 Received: (qmail 7469 invoked from network); 9 Oct 2007 21:03:43 -0000 Received: from unknown (HELO ?192.168.0.3?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Oct 2007 21:03:43 -0000 Message-ID: <470BECA5.3070801@codesourcery.com> Date: Tue, 09 Oct 2007 21:03:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Geoffrey Keating CC: Eric Botcazou , Daniel Jacobowitz , gcc-patches List , Andrew Haley Subject: Re: Don't set DECL_IGNORED_P on a cdtor function References: <20071004212317.7FA2C7771263@geoffk5.apple.com> <200710071130.25478.ebotcazou@adacore.com> <470AAED9.9010207@codesourcery.com> <200710090220.10904.ebotcazou@adacore.com> <470ACCBE.5010509@codesourcery.com> <05DDE86C-505D-46FD-9594-C11331D0D4BA@apple.com> In-Reply-To: <05DDE86C-505D-46FD-9594-C11331D0D4BA@apple.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg00511.txt.bz2 Geoffrey Keating wrote: >>>> The key issues are that (a) we have no source for these >>>> compiler-generated functions, and (b) they don't correspond to anything >>>> in the source program. If I say "step" off the end of a C++ "main", I >>>> don't want to end up in one of these functions; I want to end up in the >>>> first C++ destructor being called by them. That's the C++ view of the >>>> world; these cdtor functions are just implementation details. > The entire paragraph under 'Eric Botcazou wrote' lists reasons why my > patch is correct. > > "(a)": well, if you don't have source, tell the debugger that, rather > than having the debugger associate it with the last line in the previous > function. In practice, what happens with your patch? What file/line information (if any) is associated with the function? (I'd rather hope that the debugger was clever enough to associate regions with no debug information with the nearby ELF (or equivalent) object file symbols, rather than glomming it onto the previous function, but that's a separate issue.) > "(b)": this is what DECL_ARTIFICIAL is for, but it has no effect if > there's no debug information. I do see a good argument for generating debug info for these functions: language-level constructors and destructors may be inlined into them. So, I guess we'd ideally like to have most of the function be invisible to the debugger, but we'd like the inlined functions to show up. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713