From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30649 invoked by alias); 18 Jan 2007 18:34:48 -0000 Received: (qmail 30638 invoked by uid 22791); 18 Jan 2007 18:34:48 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 Jan 2007 18:34:39 +0000 Received: (qmail 6428 invoked from network); 18 Jan 2007 18:34:37 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Jan 2007 18:34:37 -0000 To: Frederic RISS Cc: Daniel Jacobowitz , =?utf-8?B?RnLDqWTDqXJpYw==?= Riss , Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: [RFC] Prints the frame id when target stops References: <45AB9A7F.1090502@st.com> <17837.16328.46414.146270@kahikatea.snap.net.nz> <200701170234.34303.ghost@cs.msu.su> <200701172128.l0HLSOTc024176@brahms.sibelius.xs4all.nl> <1169071153.5155.71.camel@funkylaptop> <20070117221742.GA15116@nevyn.them.org> <1169107060.3288.126.camel@localhost.localdomain> From: Jim Blandy Date: Thu, 18 Jan 2007 18:34:00 -0000 In-Reply-To: <1169107060.3288.126.camel@localhost.localdomain> (Frederic RISS's message of "Thu, 18 Jan 2007 08:57:40 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00403.txt.bz2 Frederic RISS writes: >> I suspect you can only do this in stepi, really - step/next can end up >> in strange places... > > ... and end up in a frame with the same frame id? Seems unlikely, but > then GDB isn't the place where you'd want to trade accuracy for a very > small speedup. Yeah --- I'd be very concerned about GDB performance optimizations that would cause GDB to not notice, say, corruptions of the stack by buffer overruns. If it's common for memory reads to be so expensive, you should buy a better JTAG unit^W^W^W^W^W^W^W I'd rather we work on minimizing memory accesses by unwinders than make assumptions which may not hold in buggy programs. Could you enable 'debug remote' while it's doing the unwinding, and figure out what it's actually fetching?