From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21978 invoked by alias); 20 Aug 2002 20:46:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21930 invoked from network); 20 Aug 2002 20:46:02 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 20 Aug 2002 20:46:02 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id CF9133C9C; Tue, 20 Aug 2002 16:46:00 -0400 (EDT) Message-ID: <3D62AA88.5080508@ges.redhat.com> Date: Tue, 20 Aug 2002 13:46:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Seitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] register_modified_event References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00615.txt.bz2 > On Mon, 19 Aug 2002, Andrew Cagney wrote: > > >> I don't the register_modified (the changelog called it register_update) >> is correct. Trying to supply a register number, for instance, is just >> misleading. > > > (ChangeLog is wrong, of course. It should be register_modified, not > register_update.) As for supplying register numbers, I think you'd > better take another look at MI's command set. Everything (except > data-list-register-names) returns register numbers. In fact, there is no > way to find out what the numbers mean at all with the current MI command > set! (We're not talking about register numbers vs names. You can figure out a name/number map from the command that returns the register names. The current implementation is broken in that on some targets, it will leave gaps. That can be fixed by either changing the interface or the code :-) The problem here is that trying to include the ``modified register'' in the event is misleading to the point of being dangerous. The best MI can offer the GUI is ``hey, target-changed!''. Every time the target changes, the GUI needs to refresh everything via varobj. > I presume that you mean this thread: > > http://sources.redhat.com/ml/gdb/2002-03/msg00154.html > > I guess Jim thought there were bigger fish to fry. So if a global > "target-changed" event is wanted, when is it to be sent? My understanding of JimI's comments (and I agree) is that nothing matters except how long it takes for the GUI to recover from a target changed (eg from inferior execution). Given that single step refresh performance sets an upper bound on on memory/register write refresh performance, people will always notice a slow single-step long before they notice slow writes. > When: These change the target: > o register changed by user (either via command-line or other UI) > o memory changed by user (") > o inferior execution These do not change the target: > o user changes threads (thread_command) > o user changes stack levels (frame_command, up_command, down_command) See also: http://sources.redhat.com/gdb/papers/multi-arch/real-multi-arch/index.html#SEC33 enjoy, Andrew