From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23305 invoked by alias); 29 Apr 2004 01:50:36 -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 22975 invoked from network); 29 Apr 2004 01:50:30 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 29 Apr 2004 01:50:30 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i3T1oFs2010892 for ; Wed, 28 Apr 2004 18:50:15 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Wed, 28 Apr 2004 18:50:23 -0700 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i3T1o6BD011608; Wed, 28 Apr 2004 18:50:07 -0700 (PDT) In-Reply-To: <20040429010205.GS867@gnat.com> References: <9B827536-9972-11D8-9EA7-000A9569836A@apple.com> <20040429010205.GS867@gnat.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8B069116-997F-11D8-9EA7-000A9569836A@apple.com> Content-Transfer-Encoding: 7bit Cc: Andrew Cagney , gdb-patches@sources.redhat.com From: Jason Molenda Subject: Re: Question about blockframe.c:inside_main_func() Date: Thu, 29 Apr 2004 01:50:00 -0000 To: Joel Brobecker X-SW-Source: 2004-04/txt/msg00657.txt.bz2 On Apr 28, 2004, at 6:02 PM, Joel Brobecker wrote: > Indeed, it seems that we could improve a bit this code: It really looks > like we are trying to compute the low/high addresses for function main > twice! Even when main is found within the debug info, we go through the > through the trouble of finding the bounds of function "main" from the > min syms anyway. A missing condition somewhere? Yeah, if I'm not mistaken we'll look up main() twice for each frame in a backtrace every time. With a GUI front end keeping a stack view up-to-date on each step, and apps with deep stacks, that will add up pretty fast. Here at Apple we found some real performance problems with this type of code path - things that slowed down with deep stacks and frequent 'backtraces' from the UI - so it's work fixing. Looking at the individual changes to inside_main_func, I'm pretty well convinced this is just a combination of edits that didn't look at the function's behavior overall. But it's worth checking with Andrew to see if there is some edge-case that isn't immediately obvious which would cause us to do this recomputation all the time.. J