Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sources.redhat.com
Subject: Re: Bug with i386 watchpoints
Date: Sun, 11 Nov 2001 13:01:00 -0000	[thread overview]
Message-ID: <4.2.0.58.20011123123941.00acc290@ics.u-strasbg.fr> (raw)
In-Reply-To: <8296-Wed21Nov2001203519+0200-eliz@is.elta.co.il>

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


  reply	other threads:[~2001-11-23 12:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-09  6:17 Bug with watchpoints on Linux Pierre Muller
2001-11-09  7:21 ` Eli Zaretskii
2001-11-09  9:40 ` Pierre Muller
2001-11-09 18:27   ` Pierre Muller
2001-11-10  9:44     ` Bug with i386 watchpoints Pierre Muller
2001-11-10 11:13       ` Eli Zaretskii
2001-11-11 13:01         ` Pierre Muller [this message]
2001-11-10 11:02 ` Bug with watchpoints on Linux Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4.2.0.58.20011123123941.00acc290@ics.u-strasbg.fr \
    --to=muller@cerbere.u-strasbg.fr \
    --cc=eliz@is.elta.co.il \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox