Hello,

Ref: frame->unwind->this_base()
http://sources.redhat.com/ml/gdb/2003-03/msg00238.html
Ref: cagney_framebase-20030326-branch

The attached patch introduces new per-frame methods:

	get_frame_base_address()
	get_frame_locals_address()
	get_frame_args_address()

as successors to the old FRAME_LOCALS_ADDRESS(), FRAME_ARGS_ADDRESS(), 
and get_frame_base()

These debug-info specific methods are expected to return various 
addresses, within a frame, which that same debug-info can use.  For 
instance, a frame with dwarf2 debug info would provide dwarf2 version of 
the above that return DW_AT_frame_base in all cases.

These methods are:

- per frame
Each frame, can have a different implementation.  The implementation 
being selected on the basis of the high-level debug info that needs 
those corresponding values.  One frame stabs, the next dwarf2, the next 
nothing.

- unwind netural
These methods are not tied to the frame's register unwind code.  A frame 
might mix'n'match a dwarf2 frame-base with a libunwind frame-unwind.

Going through the old methods:

FRAME_LOCALS_ADDRESS(), FRAME_ARGS_ADDRESS(): These were hard-wired to 
return a value that assumed a specific ABI and debug info.  Both those 
restrictions have been removed.

get_frame_base(): This was hardwired to return the frame->frame (what 
ever that ended up being).  Code then tried to use that value both as a 
frame identifier, and as a higher-level frame base.  It didn't work. 
New code should instead use get_frame_id() XOR get_frame_*_address().

Other stuff:

The implementation is very much modeled on the frame-unwind code.  Debug 
readers are expected to register their own high level frame-base handler.

In the case of a frame using both a prologue based frame-unwind and 
frame-base, there is an oportunity to share a common cache.  The code 
handles this with:
+  /* Sneaky: If the low-level unwind and high-level base code share a
+     common unwinder, let them share the prologue cache.  */
+  if (fi->base->unwind == fi->unwind)
+    cache = &fi->prologue_cache;
+  else
+    cache = &fi->base_cache;
so I guess that is cheap inheritance.

It adds a note to dwarf2loc and dwarf2expr pointing out that they can, 
and should, implement a dwarf2 specific frame-base.  If nothing else, 
this makes the dwarf2 frame addresses visible to the user (via `info 
frame'), which is much less confusing then the current situtation where 
`info frame' prints irellevant prologue based values :-( (there is also 
an oportunity for some value caching using the frame).

A follow on d10v change is to modify its frame ID / frame base methods 
so that they return different values.  At present they return the same 
value and that is very wrong :-(  I believe that the i386 is hitting the 
same problem.

Baring comment, I'll commit it in a week, I'll, for the moment, toss it 
on a branch.

Andrew