From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21813 invoked by alias); 29 Apr 2004 00:17:35 -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 21806 invoked from network); 29 Apr 2004 00:17:34 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sources.redhat.com with SMTP; 29 Apr 2004 00:17:34 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i3T0HT5w002040 for ; Wed, 28 Apr 2004 17:17:29 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Wed, 28 Apr 2004 17:17:33 -0700 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id i3T0HVPU021170; Wed, 28 Apr 2004 17:17:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9B827536-9972-11D8-9EA7-000A9569836A@apple.com> Content-Transfer-Encoding: 7bit Cc: gdb-patches@sources.redhat.com From: Jason Molenda Subject: Question about blockframe.c:inside_main_func() Date: Thu, 29 Apr 2004 00:17:00 -0000 To: Andrew Cagney , Joel Brobecker X-SW-Source: 2004-04/txt/msg00654.txt.bz2 Hi all, We're bringing up the currentish gdb sources here at Apple and I was debugging a problem with inside_main_func () [*] when I noticed that there seems to be a bit of extra computation that has snuck into the function during the changes since July. Previously, inside_main_func() would find the "main" function in the "symfile_objfile", find its start and end addresses (if debug symbols were present I guess) and on subsequent invocations, use those cached addresses to determine if the addr in question is contained within the "main" function. The current inside_main_func() will do msymbol = lookup_minimal_symbol (main_name (), NULL, symfile_objfile);// every time if (msymbol != NULL // once && symfile_objfile->ei.main_func_lowpc == INVALID_ENTRY_LOWPC && symfile_objfile->ei.main_func_highpc == INVALID_ENTRY_HIGHPC) if (msymbol != NULL && MSYMBOL_TYPE (msymbol) == mst_text) // every time { [... lots of stuff ...] } I realize this is hardly a performance critical function, but it's still a long shot from the version that existed before July which would find the start/end addresses and then do if (symfile_objfile->ei.main_func_lowpc == INVALID_ENTRY_LOWPC && // once symfile_objfile->ei.main_func_highpc == INVALID_ENTRY_HIGHPC) [... lookup symbol ... ] return (symfile_objfile->ei.main_func_lowpc <= pc && symfile_objfile->ei.main_func_highpc > pc); Is there some reason why this shortcut has been dropped? Is there a reason not to add a conditional to the top to detect "main"'s bounds being detected and short-circuit the searching we're doing every time. Jason [*] We have something called "ZeroLink" where the main executable -- the symfile_objfile -- is a tiny stub that demand-loads each object file (formatted like a shared library) as functions/global variables in those .o's are referenced. So in our case, the symfile_objfile doesn't contain main at all; hence me looking into this function and scratching my head about why it's re-searching for this function every time...