This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Watchpoint on an unloaded shared library(4)
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Emi SUZUKI <emi-suzuki at tjsys dot co dot jp>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 23 Sep 2009 14:26:27 -0700
- Subject: Re: Watchpoint on an unloaded shared library(4)
- References: <20090116.163825.174357636.emi-suzuki@tjsys.co.jp>
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