From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29863 invoked by alias); 21 Jun 2002 00:04: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 29776 invoked from network); 21 Jun 2002 00:04:31 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 21 Jun 2002 00:04:31 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C0DFA3D2C; Thu, 20 Jun 2002 20:04:26 -0400 (EDT) Message-ID: <3D126D8A.9020908@cygnus.com> Date: Thu, 20 Jun 2002 17:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy , Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] block_innermost_frame tweak References: <20020620131440.M397@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00409.txt.bz2 > This is similar to the code in get_frame_block that decrements the > PC before looking up its block. > > It seems to me that we generally want to use the return address - 1 > (well, ideally, the address of the `call' instruction, but we don't > have that) to decide which block any frame but the youngest is "in". > > Would it make sense to create a new function --- `frame_calling_pc', > perhaps --- which encapsulates the logic in get_frame_block, and then > use that instead of `frame->pc' in get_frame_block and > block_innermost_frame? Is there a better name? As you note, it isn't a valid PC (it may not even point into an instruction!). Further, it is isn't the address of the instruction ``calling'' the ``frame''. Last time this came up address_in_block() was used - frame_address_in_block()? > + /* To evaluate if a given PC address is within a block range, > + we normally check if PC is inside [block start .. block end[. > + However, If FRAME is not the innermost frame, then frame->pc > + normally points to the instruction *following* the call, which > + means that the comparison with the block boundaries need to be > + offset by one instruction. This is done by checking if PC is > + inside ]block start .. block end] instead. */ > + innermost = !frame->next > + || frame->next->signal_handler_caller > + || frame_in_dummy (frame->next); > + if ((innermost && frame->pc >= start && frame->pc < end) > + || (!innermost && frame->pc > start && frame->pc <= end)) > return frame; Just BTW frame_in_dummy() isn't an indication of an innermost frame. There can easily be other frames (and even dummy frames) more inner most than that dummy frame. Andrew