Re: [RFA] Have block_innermost_frame start from selected frame

[Paul Hilfinger <Hilfinger at adacore dot com>]

OK.  The discussion seems to have converged.  Here (and in the following) are
the revised patch (this time with documentation).  I will commit after a
suitable interval.  Thanks for the comments.

Paul N. Hilfinger
(Hilfinger@adacore.com)


Previously, GDB would search for the frame containing variables in a
particular lexical block starting from the current (top) frame,
ignoring any currently selected frame.  It is not clear why this is
desirable for variables that require a frame; why would a user
deliberately select one frame and then expect to see the value of a
variable in a more recent frame?  This change causes
block_innermost_frame to start looking from the selected frame, if
there is one.

This change is perhaps unnecessarily conservative.  It uses
get_selected_frame_if_set rather than get_selected_frame in order to
avoid the side effect of calling select_frame, which would probably be
harmless.

Add a paragraph to the "Program Variables" section of the texinfo
documentation concerning the use of "::" for accessing non-static variables.

2011-12-27  Paul Hilfinger  <hilfingr@adacore.com>

  * gdb/blockframe.c (block_innermost_frame): Start search from selected frame,
    if present, or otherwise the current frame.

  * gdb/doc/gdb.texinfo (Variables): Document use of :: for non-static
    variables.
---
 gdb/ChangeLog       |    5 +++++
 gdb/blockframe.c    |    9 ++++++---
 gdb/doc/ChangeLog   |    5 +++++
 gdb/doc/gdb.texinfo |   48 +++++++++++++++++++++++++++++++++++++++++++++---
 4 files changed, 61 insertions(+), 6 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 40f6169..d1b2401 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2011-12-30  Paul Hilfinger  <hilfingr@adacore.com>
+
+        * blockframe.c (block_innermost_frame): Start search from
+        selected frame, if present, or otherwise the current frame.
+
 2011-12-28  Jan Kratochvil  <jan.kratochvil@redhat.com>
 
 	* gdbarch.sh (max_insn_length): Extend the comment by unit.
diff --git a/gdb/blockframe.c b/gdb/blockframe.c
index ef53a3d..2d2b45c 100644
--- a/gdb/blockframe.c
+++ b/gdb/blockframe.c
@@ -354,8 +354,9 @@ find_pc_partial_function (CORE_ADDR pc, char **name, CORE_ADDR *address,
   return find_pc_partial_function_gnu_ifunc (pc, name, address, endaddr, NULL);
 }
 
-/* Return the innermost stack frame executing inside of BLOCK, or NULL
-   if there is no such frame.  If BLOCK is NULL, just return NULL.  */
+/* Return the innermost stack frame that is executing inside of BLOCK and is 
+ * at least as old as the selected frame. Return NULL if there is no
+ * such frame.  If BLOCK is NULL, just return NULL.  */
 
 struct frame_info *
 block_innermost_frame (const struct block *block)
@@ -370,7 +371,9 @@ block_innermost_frame (const struct block *block)
   start = BLOCK_START (block);
   end = BLOCK_END (block);
 
-  frame = get_current_frame ();
+  frame = get_selected_frame_if_set ();
+  if (frame == NULL)
+    frame = get_current_frame ();
   while (frame != NULL)
     {
       struct block *frame_block = get_frame_block (frame, NULL);
diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index 0ede40b..00e876f 100644
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,8 @@
+2011-12-30  Paul Hilfinger  <hilfingr@adacore.com>
+
+	* gdb.texinfo (Variables): Document use of :: for non-static
+	variables.
+
 2011-12-23  Kevin Pouget  <kevin.pouget@st.com>
 
 	Introduce gdb.FinishBreakpoint in Python.
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 3cd3b67..cd38e3f 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -7304,12 +7304,13 @@ examine the variable @code{b} while your program is executing inside
 the block where @code{b} is declared.
 
 @cindex variable name conflict
-There is an exception: you can refer to a variable or function whose
+You can refer to a variable or function whose
 scope is a single source file even if the current execution point is not
 in this file.  But it is possible to have more than one such variable or
 function with the same name (in different source files).  If that
 happens, referring to that name has unpredictable effects.  If you wish,
-you can specify a static variable in a particular function or file,
+you can specify a static variable in a particular function or file by
+qualifying its name
 using the colon-colon (@code{::}) notation:
 
 @cindex colon-colon, context for variables/functions
@@ -7332,8 +7333,49 @@ to print a global value of @code{x} defined in @file{f2.c}:
 (@value{GDBP}) p 'f2.c'::x
 @end smallexample
 
+The @code{::} qualifying notation is normally used for referring to
+static variables, since you typically disambiguate uses of local variables
+in functions by selecting the appropriate frame and using the
+unqualified name of the variable.  However, you may also use this notation
+to refer to local variables in frames enclosing the selected frame:
+
+@smallexample
+void
+foo (int a)
+@{
+  if (a < 10)
+      bar (a);
+  else
+      process (a);    /* Stop here */
+@}
+
+int
+bar (int a)
+@{
+  foo (a + 5);
+@}
+@end smallexample
+
+@noindent
+If you have a breakpoint at the indicated line above
+when the program executes the call @code{bar(0)}, then when the program
+stops, the commands
+
+@smallexample
+(@value{GDBP}) p a
+(@value{GDBP}) p bar::a
+(@value{GDBP}) up 2
+(@value{GDBP}) p a
+(@value{GDBP}) p bar::a
+
+@end smallexample
+
+@noindent
+will print the values @samp{10}, @samp{5}, @samp{5}, and @samp{0} in that
+order.
+
 @cindex C@t{++} scope resolution
-This use of @samp{::} is very rarely in conflict with the very similar
+These uses of @samp{::} are very rarely in conflict with the very similar
 use of the same notation in C@t{++}.  @value{GDBN} also supports use of the C@t{++}
 scope resolution operator in @value{GDBN} expressions.
 @c FIXME: Um, so what happens in one of those rare cases where it's in
-- 
1.7.0.4