From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7607 invoked by alias); 19 Jan 2007 14:28:11 -0000 Received: (qmail 7599 invoked by uid 22791); 19 Jan 2007 14:28:10 -0000 X-Spam-Check-By: sourceware.org Received: from vir-del-03.spheriq.net (HELO vir-del-03.spheriq.net) (194.50.41.42) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 19 Jan 2007 14:28:02 +0000 Received: from vir-out-01.spheriq.net ([194.50.41.30]) by vir-del-03.spheriq.net with ESMTP id l0JES0XH014311 for ; Fri, 19 Jan 2007 14:28:00 GMT Received: from vir-cus-02.spheriq.net (vir-cus-02.spheriq.net [194.50.41.86]) by vir-out-01.spheriq.net with ESMTP id l0JERvBB023727 for ; Fri, 19 Jan 2007 14:28:00 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by vir-cus-02.spheriq.net with ESMTP id l0JERt2S028390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Jan 2007 14:27:56 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7E396DA43; Fri, 19 Jan 2007 14:27:50 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B762A474F7; Fri, 19 Jan 2007 14:27:47 +0000 (GMT) Received: from [164.129.44.95] (crx595.cro.st.com [164.129.44.95]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CJL61784 (AUTH "denis pilat"); Fri, 19 Jan 2007 15:27:44 +0100 (CET) Message-ID: <45B0D560.1050906@st.com> Date: Fri, 19 Jan 2007 14:28:00 -0000 From: Denis PILAT User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Jim Blandy Cc: Frederic RISS , Daniel Jacobowitz , =?ISO-8859-1?Q?Fr=E9d=E9ric_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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00408.txt.bz2 Jim Blandy wrote: > 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? > > Our configuration does not use remote protocol, but our own protocol. If we talk about enhancing memory access, yes we'll try to reduce the number of memory accesses done by our unwinders, Fred is working on that. As there is no consensus to modify the -stack-list-frames to perform cache in a safe way, putting the frame_id (like discussed before) in the MI output allows the front end to make a compromise that isn't possible in GDB, and for some cases, the front end will be able to not get the stack list frame at all. -- Denis