Re: MI: event notification

Daniel Jacobowitz
2006-06-21T02:33:03Z

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