Re: Watchpoint on an unloaded shared library(4)

[Joel Brobecker <brobecker at adacore dot com>]

Emi,

Apologies for taking so much time for reviewing this patch.
I hope you're still interested in getting to the bottom of this.

If you are, I am wondering if you would be willing to also provide
testcases for the various bugs that you are fixing, just to make
sure that we do not re-introduce the problem in the future...

Just to summarize, you're inserting a watchpoint on a variable
that lives inside the main program, but with a condition involving
an entity that lives inside a shared library. After dlclosing
that shared library, you are unable to resume the execution of
the program because GDB fails to parse the condition, even after
having disabled the watchpoint.

My thoughts on this are two-fold:

  1. If update_watchpoint fails to parse and eval the condition,
     then I think that the watchpoint should be automatically
     disabled (the user should be notified of this).  The user
     should not have to disable it himself in order to resume
     the execution.

  2. It seems to me that it would make sense to move the fix
     inside update_watchpoint and not parse the condition if
     the watchpoint is disabled.  But the problem with that is
     that we call update_watchpoints before we change its status
     to enabled in do_enable_breakpoint so we can't do it that
     way. In my opinion, we should include the "reparse" argument
     to also mean reparse the condition as well as the expression.
     In other words, if we did not need to reparse the expression,
     why would we need to reparse the condition?

  3. It would also be nice if the debugger did not stop mysteriously
     like it did, probably when the watchpoint condition started
     failing.  I am hoping that addressing (1) will address this as
     well.

Could you try that?

-- 
Joel