Re: Variable identification

[Jim Blandy <jimb@codesourcery.com>]

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.