This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Understanding GDB frames


 > Compare the two iterations of the loop in f12() with the two
 > calls to f11(). For the calls to f11(), each has a separate
 > instantiation of the frame and thus (strictly speaking) has a
 > separate frame and a separate instance of var 'a'. In the two
 > iterations of f12(), the frame is the same one set up at the
 > beginning of the single call, and 'a' is the same variable.
 > In both cases, the PC and SP are the same.
 > 
 > How can GDB tell the difference? (using the return address
 > instead of the PC in identifying the frame is one way, but
 > then one only needs to go one level deeper to defeat it).
 > 
 > Does GDB need to tell the difference?
 > 
 > GDB confronts a similar issue with watchpoints on local vars.
 > It uses a special scope breakpoint to detect the return of the
 > function and thus detect the watched variable going out of
 > scope. That mechanism is not used for MI variables. Is that
 > because the extra overhead is tolerable if a watchpoint is
 > set but not otherwise?

Watchpoints are different to variable objects in that they stop execution,
when their value changes, for example.  Presumably when the vlaue is being
monitored, so too can the scope.  Variable objects are only updated (if
requested) after execution has already stopped.

 > Should scoping of MI vars be treated the same as watched vars?

As watchpoints?  I  don't think so.  A closer analogy to variable objects
is the "display" command.  There, GDB allows expressions to come back into
scope.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]