Re: [RFA] Don't reset watchpoint block on solib load.

[Jim Blandy <jimb at codesourcery dot com>]

Actually, let me withdraw the three steps I suggested above.  I
understand that I'm straying from commenting on your patch ---
apologies --- but that's because as I tried to think about it, I
became confused about what behavior we actually want to get out of
GDB.


Here's the behavior I think we actually want:

A watchpoint should 'stick' to the scope it was originally set in.
For example, suppose I have a shared library libx.so with a source
file x.c, and that x.c has a static variable S.  And suppose there's
also a global variable named S defined in the main program.  While
control is stopped somewhere in x.c, I set a watchpoint on S.
Clearly, that watchpoint refers to x.c's static S, not the global S.

Now, if I later unload libx.so, the watchpoint should delete itself
with an appropriate message, just as a watchpoint on a stack variable
does when its frame is popped --- when a shared library is unloaded,
that ends the lifetimes of the variables it defines, just as exiting a
block ends the lifetimes of the variables defined in the block.

But specifically, the watchpoint should *not* transform into a
watchpoint on the global S.  That's an entirely different variable; it
could even have a different type.  This is what I mean by a watchpoint
'sticking' to the scope it was set in.

So, opening and closing shared libraries should never cause us to
re-parse a watchpoint's expression.  Loading a shared library should
never re-parse a watchpoint expression, because the watchpoint should
stick to its original scope, which is still there.  Unloading a shared
library should never re-parse the watchpoint expression, but it should
delete the watchpoint if it refers to variables from shared library,
since they're gone now.

This isn't what GDB does now, but I think this behavior is not hard to
obtain.  When we set a watchpoint, instead of b->exp_valid_block, we
should record the PC in whose scope we parsed the expression.  When we
check a watchpoint's condition, we should look up the PC's block: if
we can't find one, then we've unloaded symbolic information for that
watchpoint, and we should delete it.

The tricky part is deciding what to do when the main executable file
is modified.  It's hard to see what exactly the watchpoint should
stick to in this case, since the PC isn't a reliable identifier across
such changes.  Perhaps it would be enough to also record the name of
the function and source file the PC falls in, re-parse if they have
remained stable, and delete the watchpoint if they have changed.