From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31562 invoked by alias); 21 Nov 2003 20:07:54 -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 31555 invoked from network); 21 Nov 2003 20:07:54 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 21 Nov 2003 20:07:54 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id A0DC5C6AA; Fri, 21 Nov 2003 12:07:53 -0800 (PST) To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa:symtab] deprecate inside_entry_func References: <3FA2F940.5040102@redhat.com> <3FBE6D46.4070201@redhat.com> From: David Carlton Date: Fri, 21 Nov 2003 20:07:00 -0000 In-Reply-To: <3FBE6D46.4070201@redhat.com> (Andrew Cagney's message of "Fri, 21 Nov 2003 14:53:42 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-11/txt/msg00443.txt.bz2 On Fri, 21 Nov 2003 14:53:42 -0500, Andrew Cagney said: >> This patch deprecates the function inside_entry_func. >> PS: Ref: >> http://sources.redhat.com/ml/gdb-patches/2003-10/msg00533.html I skimmed this, though I haven't been following the discussion too closely. But I don't quite understand the philosophical stance here - on the one hand, I see: > This way all calls to inside_entry_func have been eliminated from > up-to-date code. which suggests that you want to get rid of the idea of inside_entry_func(PC) entirely, but on the other hand I see: > + NOTE: cagney/2003-11-21: Deprecate this specific _mechanism_ for > + determining if the PC is inside the entry function. While there's > + nothing technically wrong with the idea of using "PC inside entry > + function" as a condition for terminating a backtrace, there's > + something seriously wrong with this specific implementation. It > + forces the symbol table code to go through all sorts of symbol > + table load and relocation hoops just to get the test right. which suggests that you just want to get rid of the implementation. So which is it? It seems to me that the renaming you propose suggests that the interface should go away, but the above comment suggests that you're happy with the interface, you just don't like the implementation. If you're happy with the interface, it seems to me that the proper thing to do is to add a big FIXME comment to inside_entry_func. If for some reason you think that isn't strong enough, then I could imagine renaming it to something like "broken_inside_entry_func". But I don't like renaming it to deprecated_inside_entry_func if the above NOTE is accurate. (I don't have any opinion one way or another as to whether it's better to deprecate the interface or to just flag the implementation as broken.) David Carlton carlton@kealia.com