Variable identification (Was: [RFA] Don't reset watchpoint block on solib load.)

[Vladimir Prus <ghost@cs.msu.su>]

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.

- Volodya