This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Variable identification
- From: Michael Snyder <msnyder at specifix dot com>
- To: Jim Blandy <jimb at codesourcery dot com>
- Cc: Vladimir Prus <ghost at cs dot msu dot su>, gdb-patches at sources dot redhat dot com
- Date: Fri, 30 Nov 2007 17:34:34 -0800
- Subject: Re: Variable identification
- References: <200711202013.47537.vladimir@codesourcery.com> <ur6i91xx7.fsf@gnu.org> <m3lk8gkhm8.fsf@codesourcery.com> <fin2d1$6lh$1@ger.gmane.org> <1196384986.2501.141.camel@localhost.localdomain> <m3oddbtcrt.fsf@codesourcery.com>
On Fri, 2007-11-30 at 17:38 -0800, Jim Blandy wrote:
> Michael Snyder <msnyder at specifix.com> writes:
> > On Thu, 2007-11-29 at 22:02 +0300, Vladimir Prus wrote:
> >> Jim Blandy wrote:
> >>
> >> >> This is probably good behaviour, indeed. Or maybe we should not
> >> >> disable watchpoint, but mark it as pending, in the same sense of
> >> >> "user wanted it to be enabled, but it won't trigger until a shared
> >> >> lib is loaded" that is used for ordinary watchpoints.
> >> >
> >> > I think so, too. I guess the key observation is that, while it's not
> >> > meaningful to talk about a particular local variable "coming back
> >> > alive", since each function call creates a distinct set of local
> >> > variables, and you can have recursion, etc., it is meaningful to talk
> >> > about a shared library being reloaded, and it's intuitive to identify
> >> > the 'X' from the first loading with the 'X' in the second loading,
> >> > even if they're at different addresses.
> >>
> >> Yes. I now recall this is more general problem with identification of
> >> variables in GDB. Say, you're in function, and you have local variable
> >> 'foo'. In GUI, you do something with 'foo' -- set display format to
> >> hex, expand it, and so on. It's highly desirable to keep this
> >> information for the next run of program, or even next run of the GUI --
> >> even if variable is local, it's not likely that the display properties
> >> user wants depend on frame.
> >>
> >> Unfortunately, there's no way to do that.
> >
> > I haven't followed the discussion closely, but
> > shouldn't it be up to the GUI to keep such persistant
> > info? It's nothing to do with gdb, really. It's the
> > GUI's state.
>
> These questions all affect how watchpoints behave in the CLI as well.
Right, with the CLI being a special case of "the GUI" -- one
in which we (gdb maintainers) have control of everything.
GDB can keep track of the CLI "state", but other GUI
should keep track of their own state.