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