This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] Possible bug with i386 watchpoints on several targets.
- From: Pierre Muller <muller at cerbere dot u-strasbg dot fr>
- To: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 03 Dec 2001 10:27:31 +0100
- Subject: Re: [RFC] Possible bug with i386 watchpoints on several targets.
- References: <firstname.lastname@example.org><email@example.com><firstname.lastname@example.org><email@example.com><firstname.lastname@example.org><email@example.com>
At 20:48 30/11/2001 , Eli Zaretskii a écrit:
> > Date: Fri, 30 Nov 2001 17:04:58 +0100
> > From: Pierre Muller <firstname.lastname@example.org>
> > use the following command
> > (top-gdb) watch gdb_stdout
> > (top-gdb) r
> > Here you should get a stop due to the setting of gdb_stdout value.
> > (top-gdb) cont
> > you should now reach the debuggee command prompt,
> > simply quit.
> > (gdb) quit
> > and rerun the same executable without any watchpoint modification.
> > (top-gdb) run
> > if the bug that I found on both win32 (without i386_cleanup_deregs call)
> > and on current (a few days old) CVS for linux.
> > You won't get any stop on the second run.
>This has nothing to do with i386_cleanup_dregs or, indeed, the x86
>watchpoint support. Type "maintenance show-debug-regs", and you will
>see that the watchpoint does trigger on the second run, but GDB
>ignores it. It ignores the watchpoint because the old and the new
>values compare equal on the second run, so GDB thinks it's a false
No, sorry, but I don't agree here:
I retested with today CVS compiled for i386 linux .
Of course i386_stopped_data_address gets called, but if you
set a breakpoint on the end of this function and add the condition
' cond X ret != 0'
Then you will clearly see that the behavior is wrong:
only on the first run after setting a hardware watchpoint you will get
a non zero return value for this watchpoint.
The reason is that on the second run
i386_linux_drset is not called again on the second run.
And its not called again because in i386_insert_aligned_watchpoint
I386_DR_LOW_SET_ADDR (i, addr);
are only called if the the debug register is used for the first time.
As the i386_cleanup_dregs is never called for linux target,
the internal state of the dr_mirror and dr_ref_count
is wrong on the second start.
dr_mirror still contains the hardware watchpoint address
and dr_ref_count contains one.
Thus the enabling of the hardware watchpoint only
does increment dr_ref_count (line 334)
and no linux specifc functions are called.
This is exactly the same behaviour as
what I got before calling i386_cleanup_dregs
for the cygwin target.
>The reason that hardware watchpoints are only considered to fire when
>the watched value changes is that hardware watchpoints are treated teh
>same as software watchpoints, and software watchpoints obviously
>cannot fire unless the watched value changes.
>I think it is fundamentally wrong to treat hardware and software
>watchpoints in a similar way. I think hardware watchpoints should be
>treated like read and access watchpoints, not like software
>watchpoints. If others (mainly Michael Snyder) agree, I will submit a
>patch that will make that change, and will also solve this particular
>problem raised by Pierre.
There may be different solutions to the problem above, but I
think that in any case, we need to reset dr_mirror and dr_ref_count
array at each new start.
I believe that this would be enough to solve all current troubles.
PS: A propos unwanted output of the cygwin target
using debug registers, I find the same sort of unwanted output for the linux target,
probably due to the removal/reinsertion of hardware watchpoints
when loading dynamic libraries.
Institut Charles Sadron
F 67083 STRASBOURG CEDEX (France)
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99