From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6862 invoked by alias); 20 Aug 2002 16:36:24 -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 6855 invoked from network); 20 Aug 2002 16:36:24 -0000 Received: from unknown (HELO valrhona.uglyboxes.com) (64.1.192.220) by sources.redhat.com with SMTP; 20 Aug 2002 16:36:24 -0000 Received: from localhost.localdomain (IDENT:iDcThcvYTghXlngjjJkw91rAQ5bWXkcf@localhost.localdomain [127.0.0.1]) by valrhona.uglyboxes.com (8.11.6/8.11.6) with ESMTP id g7KGd4L01710; Tue, 20 Aug 2002 09:39:05 -0700 Date: Tue, 20 Aug 2002 09:36:00 -0000 From: Keith Seitz X-X-Sender: keiths@valrhona.uglyboxes.com To: Andrew Cagney cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] register_modified_event In-Reply-To: <3D617604.3000900@ges.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-08/txt/msg00596.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! $ ./gdb -nw -nx -i=mi GNU gdb 2002-08-19-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". (gdb) -file-exec-and-symbols gdb ^done (gdb) -data-list-register-names ^done,register-names=["eax","ecx","edx","ebx","esp","ebp","esi","edi","eip","eflags","cs","ss","ds","es","fs","gs","st0","st1","st2","st3","st4","st5","st6","st7","fctrl","fstat","ftag","fiseg","fioff","foseg","fooff","fop","xmm0","xmm1","xmm2","xmm3","xmm4","xmm5","xmm6","xmm7","mxcsr","orig_eax","mm0","mm1","mm2","mm3","mm4","mm5","mm6","mm7"] (gdb) -break-insert main ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0808c756",func="main",file="../../src/gdb/main.c",line="741",times="0"} (gdb) -exec-run ^running (gdb) *stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x0808c756",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff004"}],file="../../src/gdb/main.c",line="741"} (gdb) -data-list-register-values x 0 ^done,register-values=[{number="0",register-values=[{number="0",value="0x8456784"}] (gdb) -data-list-changed-registers ^done,changed-registers=["0","3","4","5","6","7","8","9","10","11","12","13","16","18","20","21","23","24","26","27","28","29","30","31","40","41"] I've already got another patch which modified data-list-register-names to get at the numbers, but I'm guessing that isn't quite what you had in mind. Am I correct in assuming that you want me to change the above to return names (easy to do) and to take anything which takes a number as input and change it to accepting a register name (which means a lot of looping)? > See: > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=469 > > There is also a number of postings to gdb@ about this (I think it was > JimI last major posting). 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? When: o register changed by user (either via command-line or other UI) o memory changed by user (") o inferior execution o user changes threads (thread_command) o user changes stack levels (frame_command, up_command, down_command) I presume for the first two events, the third being implicit, and the last two getting events of their own. Am I anywhere near the mark? Keith