Bug with watchpoints on Linux

Bug with watchpoints on Linux

[Pierre Muller]

   There seems to be a big problem with
hardware watchpoints under Linux.

   If I compile a simple program :

/* START of twatch.c */
static int x,y;
int
main ()
{
   x = 5;
   y = x * 2;
   x = y / 2;
   x = 7;
   return 0;
}
/* END of twatch.c */
and set a hardware watchpoint on variable 'x',
the debugger correctly stops at each program location where this global var 
is changed.

   But at the second run, the program is never stopped because
of the changes to this global variable.

   It seems like there is a problem with the hardware watchpoint
resetting.

   I tested this on only one Linux machine,
but both the main and the 5.1 branches show this problem.


   The current main CVS tree with a patch (not yet submitted)
to add hardware watchpoints on cygwin target does not
have this problem (It works but there are still some problems).

This makes me suspect that the problem is truely Linux specific.

   Is this a known Linux problem of version 5.1 ?




Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: Bug with watchpoints on Linux

[Eli Zaretskii]

On Wed, 21 Nov 2001, Pierre Muller wrote:

>    But at the second run, the program is never stopped because
> of the changes to this global variable.
> 
>    It seems like there is a problem with the hardware watchpoint
> resetting.

IIRC, GDB removes the watchpoints when the program exits.  You should see 
a message to that effect, and "info breakpoints" should reflect it.

If that's not what you see, it's possible that there's a bug somewhere.

You could try the maint comamnd show-debug-regs to see what is going on 
with watchpoints.

Re: Bug with watchpoints on Linux

[Pierre Muller]

At 13:01 21/11/2001 , vous avez écrit:

>   There seems to be a big problem with
>hardware watchpoints under Linux.
>
>   If I compile a simple program :
>
>/* START of twatch.c */
>static int x,y;
>int
>main ()
>{
>   x = 5;
>   y = x * 2;
>   x = y / 2;
>   x = 7;
>   return 0;
>}
>/* END of twatch.c */
>and set a hardware watchpoint on variable 'x',
>the debugger correctly stops at each program location where this global 
>var is changed.
>
>   But at the second run, the program is never stopped because
>of the changes to this global variable.
>
>   It seems like there is a problem with the hardware watchpoint
>resetting.
>
>   I tested this on only one Linux machine,
>but both the main and the 5.1 branches show this problem.
>
>
>   The current main CVS tree with a patch (not yet submitted)
>to add hardware watchpoints on cygwin target does not
>have this problem (It works but there are still some problems).

Whoops, I was too fast once again...

I do see the same problem in my cygwin implementation ...

>This makes me suspect that the problem is truely Linux specific.
>
>   Is this a known Linux problem of version 5.1 ?

   Is this a known problem for i386 hardware watches ?


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: Bug with watchpoints on Linux

[Pierre Muller]

At 13:12 21/11/2001 , Pierre Muller a écrit:
>At 13:01 21/11/2001 , vous avez écrit:
>
>>   There seems to be a big problem with
>>hardware watchpoints under Linux.
>>
>>   If I compile a simple program :
>>
>>/* START of twatch.c */
>>static int x,y;
>>int
>>main ()
>>{
>>   x = 5;
>>   y = x * 2;
>>   x = y / 2;
>>   x = 7;
>>   return 0;
>>}
>>/* END of twatch.c */
>>and set a hardware watchpoint on variable 'x',
>>the debugger correctly stops at each program location where this global 
>>var is changed.
>>
>>   But at the second run, the program is never stopped because
>>of the changes to this global variable.
>>
>>   It seems like there is a problem with the hardware watchpoint
>>resetting.
>>
>>   I tested this on only one Linux machine,
>>but both the main and the 5.1 branches show this problem.
>>
>>
>>   The current main CVS tree with a patch (not yet submitted)
>>to add hardware watchpoints on cygwin target does not
>>have this problem (It works but there are still some problems).
>
>Whoops, I was too fast once again...
>
>I do see the same problem in my cygwin implementation ...

   I now see :
   only the go32-nat.c code does call
   i386_clean_dregs function.
I didn't have it in my cygwin patch,
and it also does not appear in
any other gdb dir source.

    This is probably the cause of the problem,
it does indeed solve the bug for cygwin if I add this call to
child_mourn_inferior as go32-nat code does.

   Probably the same will fix the bug for linux too, but I can't try this 
out now...



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Bug with i386 watchpoints

[Pierre Muller]

At 13:22 21/11/2001 , Pierre Muller a écrit:
>At 13:12 21/11/2001 , Pierre Muller a écrit:
>>At 13:01 21/11/2001 , vous avez écrit:
>>
>>>   There seems to be a big problem with
>>>hardware watchpoints under Linux.
>>>
>>>   If I compile a simple program :
>>>
>>>/* START of twatch.c */
>>>static int x,y;
>>>int
>>>main ()
>>>{
>>>   x = 5;
>>>   y = x * 2;
>>>   x = y / 2;
>>>   x = 7;
>>>   return 0;
>>>}
>>>/* END of twatch.c */
>>>and set a hardware watchpoint on variable 'x',
>>>the debugger correctly stops at each program location where this global 
>>>var is changed.
>>>
>>>   But at the second run, the program is never stopped because
>>>of the changes to this global variable.
>>>
>>>   It seems like there is a problem with the hardware watchpoint
>>>resetting.
>>>
>>>   I tested this on only one Linux machine,
>>>but both the main and the 5.1 branches show this problem.
>>>
>>>
>>>   The current main CVS tree with a patch (not yet submitted)
>>>to add hardware watchpoints on cygwin target does not
>>>have this problem (It works but there are still some problems).
>>
>>Whoops, I was too fast once again...
>>
>>I do see the same problem in my cygwin implementation ...
>
>   I now see :
>   only the go32-nat.c code does call
>   i386_clean_dregs function.
>I didn't have it in my cygwin patch,
>and it also does not appear in
>any other gdb dir source.
>
>    This is probably the cause of the problem,
>it does indeed solve the bug for cygwin if I add this call to
>child_mourn_inferior as go32-nat code does.
>
>   Probably the same will fix the bug for linux too, but I can't try this 
> out now...

   I tried to look into the i386 linux files but I don't really know into 
which file
we should add this call to i386_cleanup_dregs.

    Eli, does the i386_cleanup_dregs also get called if you kill your debugged
program ? I suspect not, maybe this should be tested.

    Are there other i386 targets that might suffer from the lack of
call to i386_cleanup_dregs ?



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: Bug with watchpoints on Linux

[Eli Zaretskii]

> Date: Wed, 21 Nov 2001 13:01:59 +0100
> From: Pierre Muller <muller@cerbere.u-strasbg.fr>
> 
>    But at the second run, the program is never stopped because
> of the changes to this global variable.
> 
>    It seems like there is a problem with the hardware watchpoint
> resetting.
> 
>    I tested this on only one Linux machine,
> but both the main and the 5.1 branches show this problem.

The DJGPP port doesn't have this problem.

Re: Bug with i386 watchpoints

[Eli Zaretskii]

> Date: Wed, 21 Nov 2001 14:07:03 +0100
> From: Pierre Muller <muller@cerbere.u-strasbg.fr>
> 
> >>I do see the same problem in my cygwin implementation ...
> >
> >   I now see :
> >   only the go32-nat.c code does call
> >   i386_clean_dregs function.
> >I didn't have it in my cygwin patch,
> >and it also does not appear in
> >any other gdb dir source.
> >
> >    This is probably the cause of the problem,
> >it does indeed solve the bug for cygwin if I add this call to
> >child_mourn_inferior as go32-nat code does.
> >
> >   Probably the same will fix the bug for linux too, but I can't try this 
> > out now...
> 
>    I tried to look into the i386 linux files but I don't really know into 
> which file
> we should add this call to i386_cleanup_dregs.
> 
>     Eli, does the i386_cleanup_dregs also get called if you kill
> your debugged program ? I suspect not, maybe this should be tested.

I don't think the missing call to i386_cleanup_dregs is the reason
for the problems you see.  That function shouldn't be needed for any
Unix style port of GDB, because when the debuggee exits, the OS
should clean up the watchpoint information from its own internal data
structures.

The DJGPP port does call i386_cleanup_dregs because in that port, the
OS doesn't know diddley-squat about the watchpoints (or, indeed, about
the fact that GDB is running another program), and so go32-nat.c
inserts the watchpoints every time it is going to run the debuggee.
To insert the watchpoints, go32-nat.c uses the data in the dr_*
arrays, so if they are not cleaned up when the debuggee exits,
go32-nat.c will not DTRT (insert watchpoints you don't want, etc.).

I suggest to use the maint show-debug-regs command to see what is
going wrong with the watchpoints when you restart the debuggee.  If
you cannot figure out what the output tells, post it here.

Re: Bug with i386 watchpoints

[Pierre Muller]

At 19:35 21/11/2001 , Eli Zaretskii a écrit:
> > Date: Wed, 21 Nov 2001 14:07:03 +0100
> > From: Pierre Muller <muller@cerbere.u-strasbg.fr>
> >
> > >>I do see the same problem in my cygwin implementation ...
> > >
> > >   I now see :
> > >   only the go32-nat.c code does call
> > >   i386_clean_dregs function.
> > >I didn't have it in my cygwin patch,
> > >and it also does not appear in
> > >any other gdb dir source.
> > >
> > >    This is probably the cause of the problem,
> > >it does indeed solve the bug for cygwin if I add this call to
> > >child_mourn_inferior as go32-nat code does.
> > >
> > >   Probably the same will fix the bug for linux too, but I can't try this
> > > out now...
> >
> >    I tried to look into the i386 linux files but I don't really know into
> > which file
> > we should add this call to i386_cleanup_dregs.
> >
> >     Eli, does the i386_cleanup_dregs also get called if you kill
> > your debugged program ? I suspect not, maybe this should be tested.
>
>I don't think the missing call to i386_cleanup_dregs is the reason
>for the problems you see.  That function shouldn't be needed for any
>Unix style port of GDB, because when the debuggee exits, the OS
>should clean up the watchpoint information from its own internal data
>structures.
>
>The DJGPP port does call i386_cleanup_dregs because in that port, the
>OS doesn't know diddley-squat about the watchpoints (or, indeed, about
>the fact that GDB is running another program), and so go32-nat.c
>inserts the watchpoints every time it is going to run the debuggee.
>To insert the watchpoints, go32-nat.c uses the data in the dr_*
>arrays, so if they are not cleaned up when the debuggee exits,
>go32-nat.c will not DTRT (insert watchpoints you don't want, etc.).
>
>I suggest to use the maint show-debug-regs command to see what is
>going wrong with the watchpoints when you restart the debuggee.  If
>you cannot figure out what the output tells, post it here.

   The problem (checked by remove the call to i386_cleanup_dregs
in my cygwin implementation) that
the last call before program end is a insert_watchpoint.
This leads to the fact the the refcount is then set to more the one
when I do rerun the debuggee.

Each time a debuggee is rerun (after normal exit at least,
I didn't check what happens with kill)
the refcount gets incremented by one.

   If I add a new watchpoint, it gets caught the first run after I set it,
(i.e. when refcount is one) but never in the runs after...

   The reason it does not work if refcount is > 0 is that
I386_DR_LOW_SET_CONTROL is not used in that case ....

   So I really think that there is a bug here that can easily be solved,
either by adding i386_cleanup_dregs to all targets using i386 hardware 
watchpoints
or by calling I386_DR_LOW_SET_CONTROL even if refcount is > 0,
but this really is a bad hack has the refcount will still be wrong....


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99