From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20735 invoked by alias); 4 Oct 2002 17:51:41 -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 20609 invoked from network); 4 Oct 2002 17:51:08 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 4 Oct 2002 17:51:08 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g94HVvX01635 for ; Fri, 4 Oct 2002 13:31:57 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g94Hp8f15093; Fri, 4 Oct 2002 13:51:08 -0400 Received: from valrhona.uglyboxes.com (IDENT:TrLuxj4dmpIMVLLSrk2Z8DO/uWHHauaJ@vpn50-62.rdu.redhat.com [172.16.50.62]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g94Hp7818426; Fri, 4 Oct 2002 13:51:07 -0400 Date: Fri, 04 Oct 2002 10:51:00 -0000 From: Keith Seitz X-X-Sender: keiths@valrhona.uglyboxes.com To: Alain Magloire cc: "J. Johnston" , Subject: Re: Patch for gdb/mi problem 702 In-Reply-To: <200210041725.NAA27681@node1.ott.qnx.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-SW-Source: 2002-10/txt/msg00132.txt.bz2 On Fri, 4 Oct 2002, Alain Magloire wrote: > Yes, as J. Johnston was saying, it was more in the case: > you write to a memory, the memory is actually pointing to some variables. > You would want the change events for the variables affected also, > We do actually send the ChangeEvent on behalf of gdb in eclipse, but > we do not know of the side-effects. That's because you're using an older version of gdb. If you were developing on CVS head, you would soon get: (gdb) -var-create - * &argc ^done,name="var1",numchild="1",type="int *" (gdb) -var-list-children var1 ^done,numchild="1",children={child={name="var1.*&argc",exp="*&argc",numchild="0",type="int"}} (gdb) &"set *(int*)&argc = 32\n" =target-changed ^done (gdb) -var-update * ^done,changelist={name="var1.*&argc",in_scope="true",type_changed="false"} (gdb) > The target_changed does not specify who is affected, which force a > cascade of -var-evaluate-expression of all the objects. It could potentially cause a cascade of -var-evaluate-expression commands and several others, too, but it does this for a reason. GDB cannot tell you what exactly happened. Your CPU could have memory-mapped registers. What if the user changes a memory address which is pointing to the stack pointer? Do you want gdb to know that the register and the memory and a variable has changed and send you update events for all three? I don't cannot even imagine how to tell GDB to do this without a massive rewrite of GDB internals. Quite frankly, there is no way that one target_changed event can possibly introduce such a large time-lag in the UI. With target_changed, one updates: memory view viewed variables registers So on a system where the UI is displaying X bytes of memory, Y variables (varobj only -- children don't count), and Z registers, this results in: (gdb) -data-read-memory 0xbffff684 x 8 5 8 . ^done,addr="0xbffff684",nr-bytes="320",total-bytes="320",next-row="0xbffff6c4",prev-row="0xbffff644",next-page="0xbffff7c4",prev-page="0xbffff544",memory=[{addr="0xbffff684",data=["0x00000000bffff853","0xbffff891bffff872","0xbffff903bffff8cd","0xbffff933bffff915","0xbffff968bffff946","0xbffff9adbffff9a1","0xbffffb7cbffff9b9","0xbffffbafbffffb9b"],ascii="S.......r...................3...F...h...............|..........."},{addr="0xbffff6c4",data=["0xbffffc54bffffc38","0xbffffc75bffffc69","0xbffffcf8bffffcb0","0xbffffd1dbffffd09","0xbffffd33bffffd28","0xbffffd52bffffd47","0xbffffd69bffffd61","0xbffffde6bffffd7c"],ascii="8...T...i...u...................(...3...G...R...a...i...|......."},{addr="0xbffff704",data=["0xbffffe31bffffe25","0xbffffe74bffffe64","0xbffffeb2bffffe82","0xbffffeccbffffebb","0xbffffeecbffffeda","0xbfffff2abffffef7","0x00000000bfffff55","0x0383fbff00000010"],ascii="%...1...d...t...............................*...U..............."},{addr="0xbffff744",data=["0x00! 00100000000006","0x0000006400000011","0x0804803400000003","0x0000002000000004","0x0000000600000005","0x4000000000000007","0x0000000000000008","0x0808c2f000000009"],ascii="............d.......4....... ..................@................"},{addr="0xbffff784",data=["0x000001f40000000b","0x000001f40000000c","0x000001f40000000d","0x000001f40000000e","0xbffff7ce0000000f","0x0000000000000000","0x0000000000000000","0x0000000000000000"],ascii="................................................................"}] (gdb) -var-update * ^done,changelist={...} (gdb) -data-list-changed-registers ^done,changelist={...} That's an insiginificant amount of work to be done. Now if GDB cached the memory values so that it could tell you what memory changed, then this would cause even less work to be done. Keith