From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30140 invoked by alias); 20 Mar 2003 01:25:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 30041 invoked from network); 20 Mar 2003 01:25:24 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 20 Mar 2003 01:25:24 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DB4432B11; Wed, 19 Mar 2003 20:25:19 -0500 (EST) Message-ID: <3E79187F.4010607@redhat.com> Date: Thu, 20 Mar 2003 01:25:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Lazy get_frame_id() References: <3E750857.50601@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00295.txt.bz2 > It opens up the possibility of, in WFI (infrun.c, et.al.), replacing the calls: > - PC_IN_SIGTRAMP() > - PC_IN_CALL_DUMMY() > with the equivalent: get_frame_type (get_current_frame ()) == SIGTRAMP_FRAME et.al. In fact, since the computation would be done once, this would be less load on the target. So, I've got some raw GCOV data vis: new lazy main func 4092 4587 4587 gdbarch_pc_in_sigtramp 9456 9246 9385 gdbarch_deprecated_pc_in_call_dummy 3047 2837 2837 create_sentinel_frame 3739 3739 3882 d10v_frame_this_id 4296 4296 4331 d10v_frame_prev_register 35754 35754 36281 gdbsim_xfer_inferior_memory 24434 24434 24581 gdbsim_fetch_register main=mainline lazy=lazy id evaluation new=lazy id evaluation + infrun using get_frame_type() but am wondering how to interpret it. Here's an attempt: The create sentinel frame's went up slightly as it is creating more frames. This would also cause the slight rise in pc_in_call_dummy calls (since that is always checked first). The minor this_id, prev_register, and the gdbsim_XXX call reduction can be attributed entirely to the lazy id evaluation (the d10v sigtramp function doesn't do anything to the target). The important one is pc-in-sigtramp and that was reduced by 10%. So I guess this data indicates that all is ok ... Any suggestions for what else to look at? Mainline with infrun using get_prev_frame()? Andrew PS: There is also calls like: PC_IN_SIGTRAMP (prev_pc, prev_func_name) but I left them them be.