From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21227 invoked by alias); 7 Mar 2004 00:01:41 -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 21218 invoked from network); 7 Mar 2004 00:01:39 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 7 Mar 2004 00:01:39 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Azljf-0002lW-ET; Sat, 06 Mar 2004 19:01:39 -0500 Date: Sun, 07 Mar 2004 00:01:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: get_frame_func() VS get_frame_id().code Message-ID: <20040307000139.GA10524@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <4048A562.5020106@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4048A562.5020106@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00038.txt.bz2 On Fri, Mar 05, 2004 at 11:05:54AM -0500, Andrew Cagney wrote: > Hello, > > The current get_frame_func() is implemented as roughly: > > fi->prev_func.addr = get_pc_function_start (addr_in_block); > > Unfortunatly this isn't valid for a signal trampoline (or at least the > evil ones that consist of random bytes in a random memory location). > For such trampolines, get_pc_function_start [rightly] fails and "func" > ends up as zero -- not good -- a properly constructed frame ID requires > non-zero code and stack addresses. > > Fortunatly, with a bit of extra instruction pattern matching, it is > possible to identify the first instruction of a signal trampoline and > hence correctly compute the trampolines "func" address. Similarly, more > normal frames can determine the function start using the symbol table's > get_pc_function_start. > > Consequently, I think there should be mechanism for obtaining both the > symbol table and frame's idea of a function's start address. This would > mean introducing: > > - get_frame_func_by_symtab > Returns the function start according to the symbol table. Much of the > existing code (especially unwinders) would need to be updated to use this. How about just leaving this as frame_func_unwind? The only current use of frame_func_unwind that I see outside of unwinders is the implementation of get_frame_func. So we could define frame_func_unwind to attempt to find the beginning of the function at the unwound PC using the symtab. It is already the unwinder's duty to propogate the function address into the ID. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer