This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] watchthreads2.exp: gdb can drop watchpoints


On Thursday 30 April 2009 00:18:44, Doug Evans wrote:
> Hi.
> 
> I wrote this testcase to help exercise h/w watchpoints in linux gdbserver.
> [A patch I'm working on, based on Pierre's win32 patch.]
> 
> Running it with just gdb periodically fails.
> I traced this to gdb dropping watchpoints if, for example,
> an shlib breakpoint from a different thread happens at the same time
> (e.g. one happens and then while gdb is stopping the remaining threads
> the other happens?).

Yes, I've seen this before.

> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0xf7ff3101
> infrun: stopped by watchpoint
> infrun: stopped data address = 0x8049af8
> infrun: context switch
> infrun: Switching context from Thread 0xf6563bb0 (LWP 22743) to Thread 0xf6db4bb0 (LWP 22742)
> infrun: BPSTAT_WHAT_CHECK_SHLIBS
> infrun: no stepping, continue

There are two issues here.

 - If new shared libraries are loaded, it looks like
   update_watchpoint will just forget about the old value of the
   watchpoint.

 - BPSTAT_WHAT_CHECK_SHLIBS handling.  I was just mentioning something
related yesterday.  In your case, it goes something like this:  Before
deciding that the stop bpstat's main action should be
BPSTAT_WHAT_CHECK_SHLIBS, bpstat_stop_status iterated over all watchpoints
and updated all their values (see: bpstat_stop_status ->
bpstat_check_watchpoint -> watchpoint_check).  Even if a watchpoint
hit happens at the same time that a shlib is handled, GDB gives priority
to the shlib event, and immediately resumes the inferior.  linux-nat.c
will hold the watchpoint hit pending, and will still report
it afterwards, but, by the time that pending event is handled,
the watchpoint value had already been updated, and will look
like it didn't change, so GDB ignores the stop.  You'll see
this much easier if you enable 'set debug lin-lwp 1' in addition
to 'set debug infun'.  See also the current "Do not
call read_pc in startup_inferior" discussion.

On Thursday 30 April 2009 00:18:44, Doug Evans wrote:
> I don't know if you want to wait until the bug is fixed before this
> testcase can be checked in.  I won't be able to look at the bug
> for awhile but maybe someone else will, so I'm submitting this testcase.
> It (periodically) fails on i386-linux, amd64-linux (depending on
> how the o/s happened to schedule the threads of course).

Please don't add failing tests to the
testsuite (on purpose, that is :-) ).  The procedure is to open a
PR, and make the test kfail instead of failing.  I see you've already
opened a PR, so the test is OK if you make that change.

Thanks.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]