This is the mail archive of the
mailing list for the GDB project.
Re: [multi-arch] The frame as the global parameter (long, important)
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.