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
next prev parent 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