Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: muller@cerbere.u-strasbg.fr
Cc: gdb@sources.redhat.com
Subject: Re: Bug with i386 watchpoints
Date: Sat, 10 Nov 2001 11:13:00 -0000	[thread overview]
Message-ID: <8296-Wed21Nov2001203519+0200-eliz@is.elta.co.il> (raw)
In-Reply-To: <4.2.0.58.20011121140420.01afe368@ics.u-strasbg.fr> (message from Pierre Muller on Wed, 21 Nov 2001 14:07:03 +0100)

> 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.


  reply	other threads:[~2001-11-21 21:26 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 [this message]
2001-11-11 13:01         ` Pierre Muller
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=8296-Wed21Nov2001203519+0200-eliz@is.elta.co.il \
    --to=eliz@is.elta.co.il \
    --cc=gdb@sources.redhat.com \
    --cc=muller@cerbere.u-strasbg.fr \
    /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