Re: Patch for gdb/mi problem 702

[Keith Seitz <keiths at redhat dot com>]

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