From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26080 invoked by alias); 4 May 2008 19:59:26 -0000 Received: (qmail 26070 invoked by uid 22791); 4 May 2008 19:59:26 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 04 May 2008 19:59:06 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id E98EF983F0; Sun, 4 May 2008 19:59:04 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id BFA5F9829E; Sun, 4 May 2008 19:59:04 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JskMS-0004Bi-1W; Sun, 04 May 2008 15:59:04 -0400 Date: Sun, 04 May 2008 21:34:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH:MI] Event notification Message-ID: <20080504195904.GA15993@caradoc.them.org> Mail-Followup-To: Vladimir Prus , gdb-patches@sources.redhat.com References: <18439.56134.456709.118980@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) 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: 2008-05/txt/msg00185.txt.bz2 On Sun, May 04, 2008 at 03:30:56PM +0400, Vladimir Prus wrote: > I think that when execution stops, all threads have frame 0 as selected, no? Most of the time, but not necessarily. For Ada we automatically select the exception site on catch/throw events. For C++ we do not, but we ought to. > Some interesting questions arise, with the first one -- what is the exact > meaning of those new notifications and what is the expected reaction in frontend? > For example, suppose you have a bunch of fixed variable objects in different > threads. Then, -var-update * will switch between threads to evaluate the variable > objects. This, I think, will produce a bunch of thread change and frame change > notifications? What will frontend do? If a frontend updates the current > line indicator as result of those notifications, then "-var-update *" will > cause the line indicator to jump around in a fairly interesting way :-) > > One way to address this is to suppress those notification for implicit > gdb activity. I don't see how we can easily do this. Another way would > be instruct the frontends to ignore those notifications during some commands. > But then, I'm not sure how to do this without creating a huge table of > commands that implicitly change thread/stack, and without running the risk > of making the frontend act funny if we forget a command, or unintentionally > make some other command switch thread/frames. IIRC Nick added the thread switch events only when we print out [Switching] messages for the CLI, which are already at the sites of explicit activity. The other way to do it is to generate these events at prompts, either before the result or after the prompt. We're about to display a prompt so we check the selected frame against what was selected last time we displayed a prompt. It changed? Show an event. -- Daniel Jacobowitz CodeSourcery