From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9235 invoked by alias); 21 Jun 2006 02:33:03 -0000 Received: (qmail 9227 invoked by uid 22791); 21 Jun 2006 02:33:03 -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, 21 Jun 2006 02:33:00 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FssWY-00050N-Be; Tue, 20 Jun 2006 22:32:58 -0400 Date: Wed, 21 Jun 2006 04:50:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb@sourceware.org Subject: Re: MI: event notification Message-ID: <20060621023258.GA19167@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb@sourceware.org References: <17560.40409.61785.698765@kahikatea.snap.net.nz> <20060621013437.GA17956@nevyn.them.org> <17560.44395.508930.351917@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17560.44395.508930.351917@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.11+cvs20060403 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: 2006-06/txt/msg00167.txt.bz2 On Wed, Jun 21, 2006 at 02:22:35PM +1200, Nick Roberts wrote: > > > Using the patch, "=stack-changed\n" gets printed every time the stack > > > changes e.g > > > > Good idea in general, bad choice of example. This is not a valid > > optimization, at least not where you put it. > > > > - Stepping within a frame can change the values displayed by > > -stack-list-arguments. On most targets + compilers they > > are sometimes corrupt at the beginning of a function. On > > many targets the "incoming" value of the argument changes > > when that variable is assigned to. > > In this case, though, -stack-list-frames would be unchanged? Unless GDB had the backtrace wrong at one of those points, yes, it should be unchanged. > > - You can encounter the same frame ID for two consecutive stops > > but have a different backtrace, e.g. if you continued and then > > hit a breakpoint near the same function. > > Do you mean that with something like: > > ... > myproc (arg1); > myproc (arg2); > > the frame id on the second call to myproc would be identical to the > first? Presumably the output to -stack-list-frames would be unchanged > in this case also. No, think a little further outside of the box. void myproc(void) { } void a1 (void) { int x[10]; myproc(); } void a2 (void) { int x[10]; a1(); } void b (void) { int y[20]; myproc (); } int main () { a2 (); b(); } With a breakpoint on myproc. Obviously it won't work as-is because there's more on the stack, like a return address. Fiddle the numbers, and eventually it will work. > If they can give me a few clues that will be great, but I only want to trawl > through the code in Darwin, like I did for the asynchronous stuff, as a last > resort. I am hoping that this will be an easier nut to crack. Yes, I know that Jim was planning to list off their MI changes for the DMI workgroup, at some point. -- Daniel Jacobowitz CodeSourcery