From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27618 invoked by alias); 26 Apr 2006 19:19:53 -0000 Received: (qmail 27610 invoked by uid 22791); 26 Apr 2006 19:19:52 -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; Wed, 26 Apr 2006 19:19:51 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FYpYA-0007a4-2l; Wed, 26 Apr 2006 15:19:46 -0400 Date: Wed, 26 Apr 2006 19:19:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] problem fetching inferior memory due to breakpoint Message-ID: <20060426191946.GA28844@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com References: <20060426190517.GA930@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060426190517.GA930@adacore.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00346.txt.bz2 On Wed, Apr 26, 2006 at 12:05:17PM -0700, Joel Brobecker wrote: > We actually scan the function prologue during the step operation as > opposed to during the "bt", because we need to determine where we are, > and that causes us to create the frame ID for frame 0, which means > scanning the function prologue (not actually verified, all from memory, > may be incorrect - but the fact is correct: we compute the frame ID > during the step). Which seriously blows for performance. > I'm not exactly sure yet as to why we don't see this problem on x86-linux. > But all works fine there as far as I can tell. Try removing .debug_frame, to trigger the prologue analyzer? > I looked at the gdb-patches archives, and Andrew said at the time > that we should use get_frame_memory. The problem is that I don't see > how get_frame_memory() will help, since all it does is calling > read_memory(), which brings us back to our initial problem. Try safe_frame_unwind_memory, the other caller of deprecated_read_memory_nobpt. Many other prologue analyzers already seem to use that. -- Daniel Jacobowitz CodeSourcery