Just FYI,

This patch updates insight to match a proposed "frame.h" interface 
change.  Once that interface change is in, this, or an equivalent will 
(hopefully) be committed.

The patch adds a FIXME which the Insight people may want to note.  The 
appended text (part of the GDB patch) hopefully provides additional 
information on the problem.

Andrew

+/* Return the frame address from FI.  Except in the machine-dependent
+   *FRAME* macros, a frame address has no defined meaning other than
+   as a magic cookie which identifies a frame over calls to the
+   inferior (um, SEE NOTE BELOW).  The only known exception is
+   inferior.h (PC_IN_CALL_DUMMY) [ON_STACK]; see comments there.  You
+   cannot assume that a frame address contains enough information to
+   reconstruct the frame; if you want more than just to identify the
+   frame (e.g. be able to fetch variables relative to that frame),
+   then save the whole struct frame_info (and the next struct
+   frame_info, since the latter is used for fetching variables on some
+   machines) (um, again SEE NOTE BELOW).
+
+   NOTE: cagney/2002-11-18: Actually, the frame address isn't
+   sufficient for identifying a frame, and the counter examples are
+   wrong!
+
+   Code that needs to (re)identify a frame must use get_frame_id() and
+   frame_find_by_id() (and in the future, a frame_compare() function
+   instead of INNER_THAN()).  Two reasons: an architecture (e.g.,
+   ia64) can have more than one frame address (due to multiple stack
+   pointers) (frame ID is going to be expanded to accomodate this);
+   successive frameless function calls can only be differientated by
+   comparing both the frame's base and the frame's enclosing function
+   (frame_find_by_id() is going to be modified to perform this test).
+
+   The generic dummy frame version of PC_IN_CALL_DUMMY() is able to
+   identify a dummy frame using only the PC value.  So the frame
+   address is not needed.  In fact, most PC_IN_CALL_DUMMY() calls now
+   pass zero as the frame/sp values as the caller knows that those
+   values won't be used.  Once all architectures are using generic
+   dummy frames, PC_IN_CALL_DUMMY() can drop the sp/frame parameters.
+   When it comes to finding a dummy frame, the next frame's frame ID
+   (with out duing an unwind) can be used (ok, could if it wasn't for
+   the need to change the way the PPC defined frame base in a strange
+   way).
+
+   Modern architectures should be using something like dwarf2's
+   location expression to describe where a variable lives.  Such
+   expressions specify their own debug info centric frame address.
+   Consequently, a generic frame address is pretty meaningless.  */
+