From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 609 invoked by alias); 7 Nov 2003 17:31:43 -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 597 invoked from network); 7 Nov 2003 17:31:42 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 Nov 2003 17:31:42 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hA7HVgM18893 for ; Fri, 7 Nov 2003 12:31:42 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hA7HVg610181; Fri, 7 Nov 2003 12:31:42 -0500 Received: from localhost.localdomain (vpn50-2.rdu.redhat.com [172.16.50.2]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id hA7HVfH8004356; Fri, 7 Nov 2003 12:31:41 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id hA7HVaR17861; Fri, 7 Nov 2003 10:31:36 -0700 Date: Fri, 07 Nov 2003 17:31:00 -0000 From: Kevin Buettner Message-Id: <1031107173135.ZM17860@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [rfa:symtab] deprecate inside_entry_func" (Oct 31, 9:27pm) References: <3FA2F940.5040102@redhat.com> <1031101003654.ZM5020@localhost.localdomain> <3FA30271.5020908@redhat.com> <1031101005517.ZM5150@localhost.localdomain> <3FA31A0F.5060706@gnu.org> To: Andrew Cagney , Kevin Buettner Subject: Re: [rfa:symtab] deprecate inside_entry_func Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-11/txt/msg00121.txt.bz2 On Oct 31, 9:27pm, Andrew Cagney wrote: > > Kevin, you previously wrote: > > > >> >> I'd like to avoid re-introducing a dependency on inside_entry_func() as > >> >> that places garish requirements on the object file readers :-( > > > >> > > >> > I agree that object file readers should not attempt to track of > >> > the bounds of the start function. However, given an arbitrary > >> > address, it's not unreasonable to ask the symtab machinery to attempt > >> > to figure out the function bounds. And, in fact, this is just what > >> > find_pc_partial_function() does. > > > > > > Yes, the reason I wrote this was to note that there are other ways of > > implementing inside_entry_func() which wouldn't place garish > > requirements on the object file readers. > > Then I'm puzzled as to why you are objecting to me deprecating this > existing garish hack? Remember, I also wrote: > > > + /* NOTE: cagney/2003-10-31: A very simple test, such as > > + get_frame_func == entry_point should be sufficient for > > + identifying a pc in the entry function. Does anyone know why it > > + wasn't sufficient and hence, why the very convoluted > > + "deprecated_inside_entry_func" is needed. */ What I'm suggesting is that you implement inside_entry_func() using "get_frame_func == entry_point". What's so garish about that? Kevin