Re: Patch for gdb/mi problem 702

Keith Seitz
2002-10-04T17:51:41Z

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