MI: event notification

MI: event notification

[Nick Roberts]

In the past there have been discussions about the performance of certain
MI commands.  To reduce the overhead, I would like to add some event
notification where GDB informs that front end when something has changed

I think this has always been the intention but that nothing has so far
been implemented.  As a start, and by way of an example, I attach a patch
that tries to say when the stack has changed so that MI command(s)
-stack-list-frames, -stack-list-arguments need not be issued while stepping
within the same frame, for example.  

From the manual:

`NOTIFY-ASYNC-OUTPUT ==>'
     `[ TOKEN ] "=" ASYNC-OUTPUT'


Using the patch, "=stack-changed\n" gets printed every time the stack changes
e.g

(gdb)
-exec-finish
^running
(gdb)
=stack-changed
*stopped,reason="function-finished",thread-id="0",frame={addr="0x080487cc",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbff7efa4"}],file="myprog.c",fullname="/home/nickrob/myprog.c",line="112"},gdb-result-var="$1",return-value="9"
(gdb)
-exec-next
^running
(gdb)
*stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x080487d1",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbff7efa4"}],file="myprog.c",fullname="/home/nickrob/myprog.c",line="108"}
(gdb)
-exec-continue
^running
(gdb)
=stack-changed
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x080488aa",func="myprint",args=[{name="i",value="2"},{name="j",value="2"}],file="myprint.c",fullname="/home/nickrob/myprint.c",line="9"}
(gdb)


WDYT?

-- 
Nick                                           http://www.inet.net.nz/~nickrob



*** mi-main.c	13 May 2006 16:42:07 +1200	1.84
--- mi-main.c	21 Jun 2006 12:38:48 +1200	
*************** mi_execute_async_cli_command (char *mi, 
*** 1339,1344 ****
--- 1339,1346 ----
  
    if (!target_can_async_p ())
      {
+       static struct frame_id previous = {0, 0, 0, 0, 0, 0}; 
+       struct frame_id current;
        /* Do this before doing any printing.  It would appear that some
           print code leaves garbage around in the buffer. */
        do_cleanups (old_cleanups);
*************** mi_execute_async_cli_command (char *mi, 
*** 1346,1351 ****
--- 1348,1362 ----
           the stopped message. */
        if (last_async_command)
  	fputs_unfiltered (last_async_command, raw_stdout);
+       current = get_frame_id (get_current_frame ());
+       if (!frame_id_eq (previous, current))
+ 	fputs_unfiltered ("=stack-changed\n", raw_stdout);
+       previous.stack_addr = current.stack_addr;
+       previous.stack_addr_p = current.stack_addr_p;
+       previous.code_addr = current.code_addr;
+       previous.code_addr_p = current.code_addr_p;
+       previous.special_addr = current.special_addr;
+       previous.special_addr_p = current.special_addr_p;
        fputs_unfiltered ("*stopped", raw_stdout);
        mi_out_put (uiout, raw_stdout);
        mi_out_rewind (uiout);

Re: MI: event notification

[Daniel Jacobowitz]

On Wed, Jun 21, 2006 at 01:16:09PM +1200, Nick Roberts wrote:
> In the past there have been discussions about the performance of certain
> MI commands.  To reduce the overhead, I would like to add some event
> notification where GDB informs that front end when something has changed
> 
> I think this has always been the intention but that nothing has so far
> been implemented.  As a start, and by way of an example, I attach a patch
> that tries to say when the stack has changed so that MI command(s)
> -stack-list-frames, -stack-list-arguments need not be issued while stepping
> within the same frame, for example.  
> 
> From the manual:
> 
> `NOTIFY-ASYNC-OUTPUT ==>'
>      `[ TOKEN ] "=" ASYNC-OUTPUT'
> 
> 
> Using the patch, "=stack-changed\n" gets printed every time the stack changes
> e.g

Good idea in general, bad choice of example.  This is not a valid
optimization, at least not where you put it.

- Stepping within a frame can change the values displayed by
  -stack-list-arguments.  On most targets + compilers they
  are sometimes corrupt at the beginning of a function.  On
  many targets the "incoming" value of the argument changes
  when that variable is assigned to.

- You can encounter the same frame ID for two consecutive stops
  but have a different backtrace, e.g. if you continued and then
  hit a breakpoint near the same function.

A good place to start might be asking the Xcode folks where they put
events.  I know they put a bunch of them, e.g. shlib related.  I don't
know if they're all suitable for GDB/MI, but I bet most of them are.
(And I think I talked with Jim about this particular one at some point,
and they either didn't have one, or didn't use it for much).

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: event notification

[Nick Roberts]

 > > Using the patch, "=stack-changed\n" gets printed every time the stack
 > > changes e.g
 > 
 > Good idea in general, bad choice of example.  This is not a valid
 > optimization, at least not where you put it.
 > 
 > - Stepping within a frame can change the values displayed by
 >   -stack-list-arguments.  On most targets + compilers they
 >   are sometimes corrupt at the beginning of a function.  On
 >   many targets the "incoming" value of the argument changes
 >   when that variable is assigned to.

In this case, though, -stack-list-frames would be unchanged?

 > - You can encounter the same frame ID for two consecutive stops
 >   but have a different backtrace, e.g. if you continued and then
 >   hit a breakpoint near the same function.

Do you mean that with something like:

 ...
 myproc (arg1);
 myproc (arg2);

the frame id on the second call to myproc would be identical to the
first?  Presumably the output to -stack-list-frames would be unchanged
in this case also.

 > A good place to start might be asking the Xcode folks where they put
 > events.  I know they put a bunch of them, e.g. shlib related.  I don't
 > know if they're all suitable for GDB/MI, but I bet most of them are.
 > (And I think I talked with Jim about this particular one at some point,
 > and they either didn't have one, or didn't use it for much).

If they can give me a few clues that will be great, but I only want to trawl
through the code in Darwin, like I did for the asynchronous stuff, as a last
resort.  I am hoping that this will be an easier nut to crack.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: event notification

[Daniel Jacobowitz]

On Wed, Jun 21, 2006 at 02:22:35PM +1200, Nick Roberts wrote:
>  > > Using the patch, "=stack-changed\n" gets printed every time the stack
>  > > changes e.g
>  > 
>  > Good idea in general, bad choice of example.  This is not a valid
>  > optimization, at least not where you put it.
>  > 
>  > - Stepping within a frame can change the values displayed by
>  >   -stack-list-arguments.  On most targets + compilers they
>  >   are sometimes corrupt at the beginning of a function.  On
>  >   many targets the "incoming" value of the argument changes
>  >   when that variable is assigned to.
> 
> In this case, though, -stack-list-frames would be unchanged?

Unless GDB had the backtrace wrong at one of those points, yes, it
should be unchanged.

>  > - You can encounter the same frame ID for two consecutive stops
>  >   but have a different backtrace, e.g. if you continued and then
>  >   hit a breakpoint near the same function.
> 
> Do you mean that with something like:
> 
>  ...
>  myproc (arg1);
>  myproc (arg2);
> 
> the frame id on the second call to myproc would be identical to the
> first?  Presumably the output to -stack-list-frames would be unchanged
> in this case also.

No, think a little further outside of the box.

void myproc(void) { }

void a1 (void) { int x[10]; myproc(); }
void a2 (void) { int x[10]; a1(); }

void b (void) { int y[20]; myproc (); }

int main () { a2 (); b(); }

With a breakpoint on myproc.  Obviously it won't work as-is because
there's more on the stack, like a return address.  Fiddle the numbers,
and eventually it will work.

> If they can give me a few clues that will be great, but I only want to trawl
> through the code in Darwin, like I did for the asynchronous stuff, as a last
> resort.  I am hoping that this will be an easier nut to crack.

Yes, I know that Jim was planning to list off their MI changes for the
DMI workgroup, at some point.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: event notification

[Jim Ingham]

We don't do what Nick's suggesting.  We do do something similar for  
shared library notifications - we emit async notifications for shared  
library load events from gdb so Xcode doesn't have to stop on solib  
events & get the shlig list.  Similarly if a shared library load  
causes a pended breakpoint to get loaded we tell about that as well.

But we don't do anything for stack changes.  Note, except in the case  
where you have gotten stuck in some kind of pathological recursion, I  
would be surprised if it's consing up the stack list for the MI that  
takes a significant portion of the time, so I'm not sure this example  
isn't a false optimization.  But anyway, we don't do that.

Most of the notifications we use are to tell Xcode what's happening  
during -interpreter-exec, so it can keep the UI in sync with the  
console.

The
On Jun 20, 2006, at 7:32 PM, Daniel Jacobowitz wrote:

>> If they can give me a few clues that will be great, but I only want  
>> to trawl
>> through the code in Darwin, like I did for the asynchronous stuff,  
>> as a last
>> resort.  I am hoping that this will be an easier nut to crack.
>
> Yes, I know that Jim was planning to list off their MI changes for the
> DMI workgroup, at some point.
>

Re: MI: event notification

[Nick Roberts]

Jim Ingham writes:
 > We don't do what Nick's suggesting.  We do do something similar for  
 > shared library notifications - we emit async notifications for shared  
 > library load events from gdb so Xcode doesn't have to stop on solib  
 > events & get the shlig list.  Similarly if a shared library load  
 > causes a pended breakpoint to get loaded we tell about that as well.
 > 
 > But we don't do anything for stack changes.  Note, except in the case  
 > where you have gotten stuck in some kind of pathological recursion, I  
 > would be surprised if it's consing up the stack list for the MI that  
 > takes a significant portion of the time, so I'm not sure this example  
 > isn't a false optimization.  But anyway, we don't do that.

I thought previous discussion (Vladimir Prus) suggested that
-stack-list-argments, at least, was time consuming.  If the stack is 1000's of
frames deep, it must surely be time comsuming to compute and re-display it at
every step.  The depth can be restricted but I think you have said that the
first ones take are the hardest to compute.

In any case, we need to be scientific about it, so I propose to add a time
field to the MI output.  ISTR that Apple's MI already has this.  Are you
planning to include this (or the async notifications for shared librarys) in
the DMI specification?  I would like to avoid unnecessary duplication of
effort.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: event notification

[Jim Ingham]

On Jul 15, 2006, at 4:11 PM, Nick Roberts wrote:

> Jim Ingham writes:
>> We don't do what Nick's suggesting.  We do do something similar for
>> shared library notifications - we emit async notifications for shared
>> library load events from gdb so Xcode doesn't have to stop on solib
>> events & get the shlig list.  Similarly if a shared library load
>> causes a pended breakpoint to get loaded we tell about that as well.
>>
>> But we don't do anything for stack changes.  Note, except in the case
>> where you have gotten stuck in some kind of pathological recursion, I
>> would be surprised if it's consing up the stack list for the MI that
>> takes a significant portion of the time, so I'm not sure this example
>> isn't a false optimization.  But anyway, we don't do that.
>
> I thought previous discussion (Vladimir Prus) suggested that
> -stack-list-argments, at least, was time consuming.  If the stack is  
> 1000's of
> frames deep, it must surely be time comsuming to compute and re- 
> display it at
> every step.  The depth can be restricted but I think you have said  
> that the
> first ones take are the hardest to compute.

We have a simple backtracer that just follows the frame pointer, and  
doesn't do any of the fancy unwinding of registers, etc.  When I get  
it to print roughly the same information as the ordinary -stack-list- 
frames it's ~10 times faster than -stack-list-frames.  So I'm pretty  
sure most of the time in -stack-list-frames is doing real work  
computing the backtrace, and only a small portion is consing up the  
output.  To tell whether the stack has changed or not you have to do  
the backtrace (even if you don't report it.)  So my guess is this  
change wouldn't save very much time.

The shared-libraries one was a win because we got the UI out of the  
process of stopping & starting again on shared library hit.  For

>
> In any case, we need to be scientific about it, so I propose to add  
> a time
> field to the MI output.  ISTR that Apple's MI already has this.  Are  
> you
> planning to include this (or the async notifications for shared  
> librarys) in
> the DMI specification?  I would like to avoid unnecessary  
> duplication of
> effort.

Dunno if the timing belongs in the spec, since it's more of a  
diagnostic thing.  But it is really handy to have...  The shared  
library notification is really useful and probably should go in.

Jim

Re: MI: event notification

[Nick Roberts]

 > > In any case, we need to be scientific about it, so I propose to add a
 > > time field to the MI output.  ISTR that Apple's MI already has this.  Are
 > > you planning to include this (or the async notifications for shared
 > > librarys) in the DMI specification?  I would like to avoid unnecessary
 > > duplication of effort.
 > 
 > Dunno if the timing belongs in the spec, since it's more of a  
 > diagnostic thing.  But it is really handy to have...  The shared  
 > library notification is really useful and probably should go in.

If timing is not part of the DMI spec, which sounds reasonable, then I think
that should be documented too.

-- 
Nick                                           http://www.inet.net.nz/~nickrob