GDBARCH vs frame vs stacks

[Andrew Cagney]

> Rather than dumping the problem on gdbarch, I think the thing to do is
>> review the way that core-gdb interacts with a frame and determine an
>> interaction model that accomodates both existing abi and abi's based
>> around dwarf2 info. In doing this, the end result should be a good clean
>> understandable (and not dwarf2 centric) design.
> 
> 
> Sure. I just didn't want to resdesign the frame ATM, to be honest, because
> it would open up a can of worms since i'm sure everyone has *something*
> they want frames to be able to do, that they don't do now, and thus, i'd
> be getting myself into too much ATM.  There was nothing dwarf2 specific
> about my current interjection into *_get_saved_register, in actuality. I
> had added a symbol file hook (well two) for getting and evaluating call frame
> info, and made the elf reader (which is where these hooks are acutally
> used) call through to dwarf2's getting and evaluating routines (because no
> other formats we currently support support it).  All i had added to the
> actual *_get_saved_register routines was the code to get the objfile for
> the frame function, and call through to it's hook.


What I have in mind is rationalization of the frame object so that it 
does less not more.  To me the problem is that the frame abstraction is 
confused - not suprising given it has evolved over time.

The recent proposals to sort out the register interface is an example. 
It actually ends up with a smaller simpler interface.

Hopefully it is possible to look at the dwarf2 abstraction model and 
find something that is common to both it and the other debug systems.

	Andrew