From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2815 invoked by alias); 29 Nov 2005 22:14:39 -0000 Received: (qmail 2804 invoked by uid 22791); 29 Nov 2005 22:14:38 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 29 Nov 2005 22:14:36 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EhDk6-0000fI-Gw; Tue, 29 Nov 2005 17:14:30 -0500 Date: Tue, 29 Nov 2005 22:15:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: pgilliam@us.ibm.com, gdb@sources.redhat.com Subject: Re: What should be used instead of deprecated_read_memory_nobpt()? Message-ID: <20051129221430.GA2238@nevyn.them.org> Mail-Followup-To: Mark Kettenis , pgilliam@us.ibm.com, gdb@sources.redhat.com References: <200511291401.30945.pgilliam@us.ibm.com> <200511292204.jATM4R1s022362@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511292204.jATM4R1s022362@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00627.txt.bz2 On Tue, Nov 29, 2005 at 11:04:27PM +0100, Mark Kettenis wrote: > > From: Paul Gilliam > > Date: Tue, 29 Nov 2005 14:01:30 -0800 > > > > I need to write an implementation of > > 'gdbarch_in_function_epilogue_p()'. In looking for a model to use, > > I see that 'hppa_in_function_epilogue_p()' and > > 's390_in_function_epilogue_p()' both use > > 'deprecated_read_memory_nobpt()' to get instructions from the > > target, but 'sh_in_function_epilogue_p()' and > > 'xstormy16_in_function_epilogue_p()' both use > > 'read_memory_unsigned_integer()' for that purpose. > > > > Can 'read_memory_unsigned_integer()' replace 'deprecated_read_memory_nobpt()'? > > Not sure, but read_memory_unsigned_integer() might not be safe, > because of the possibility of inserted breakpoints. The safe > alternative is safe_frame_unwind_memory(). But of course that means > that in_function_epilogue_p should really be changed such that it > accepts a `struct frame *' as an argument. Which would be a good change if we really need this method anyway. I'm dubious how much good it does... -- Daniel Jacobowitz CodeSourcery, LLC