From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Nick Duffek Cc: gdb@sources.redhat.com Subject: Re: [multi-arch] The frame as the global parameter (long, important) Date: Mon, 26 Feb 2001 14:42:00 -0000 Message-id: <3A9ADB4F.DD209C8B@cygnus.com> References: <3A970102.68681EB2@cygnus.com> <200102262120.f1QLKtd00557@rtl.cygnus.com> X-SW-Source: 2001-02/msg00388.html 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