[multi-arch] The frame as the global parameter (long, important)

[Andrew Cagney]

Nick Duffek wrote:
> 
> On 23-Feb-2001, Andrew Cagney wrote:
> 
> >       o       The frame have an architecture
> >               attached to it.
> 
> Yes, this seems like the right thing to do.
> 
> >               As an intermediate hack, current
> >               architecture and current frame would
> >               remain as globals.
> 
> So eventually, current_gdbarch and selected_frame will be deprecated in
> favor of passing gdbarch and/or frame pointers as parameters?

Eventually, something kind of like that will happen - target code might
have a target object; thread code might have a thread object; ...

Here I'm just focusing on one object and its methods - the frame or
``struct frame_info *'' and making plans for fixing it.

> I wonder if that's really beneficial.  Global variables should be used
> sparingly, but they're appropriate for values shared across large expanses
> of code, as current_gdbarch and selected_frame are.

There is, in a sense, a ``secret agenda'' going on.  A recognized
problem with GDB is that it assumes it is debugging a single threaded,
single architectured, single languaged, single targeted, single framed,
VAX application.  When reviewing or proposing change I try to keep in
mind the long term objective of breaking each of those implicit
assumptions.  I think parameterising all frame methods with their frame
is consistent with that.

	enjoy,
		Andrew