From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Possible bug with i386 watchpoints on several targets.
Date: Wed, 05 Dec 2001 03:55:00 -0000 [thread overview]
Message-ID: <4.2.0.58.20011205123616.00a477a8@ics.u-strasbg.fr> (raw)
In-Reply-To: <Pine.SUN.3.91.1011205131342.7196A-100000@is>
At 12:22 05/12/2001 , vous avez écrit:
>On Wed, 5 Dec 2001, Pierre Muller wrote:
>
> > Eli, you didn't answer if you agree that
> > the call to i386_cleanup_dregs is required for all targets using
> > standard i386 hardware watchpoints.
>
>I don't know; theoretically, GDB should remove all the watchpoints from
>the debuggee on the way to exit. If all watchpoints are removed, the
>dr_* variables are cleaned up automatically.
But that is not the case for now...
I agree that this also should solve the problem,
but I don't know exactly how to do this, and if
there are reasons NOT to do so.
I think that for instance removing a normal breakpoint
will fail after program termination, if the breakpoint
is set by changing the .text section,
as the address will most probably not be accessible anymore.
Processors different from ix86 might also
need access to the memory location to remove a watchpoint successfully.
We could use function remove_hw_watchpoints,
but hardware breakpoints should probably also be removed, no ?
I don't know exactly at which location this call should be made...
>But an explicit call to i386_cleanup_dregs when the debuggee dies cannot
>possibly do any harm, so there should be no reason not to do that, if it
>is sometimes needed.
If your patch also does explicitly remove all hardware watchpoints,
the it will indeed become unneeded (probably also for go32-nat target).
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-12-05 11:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4.2.0.58.20011121124943.00a4a288@ics.u-strasbg.fr>
[not found] ` <1190-Wed21Nov2001202555+0200-eliz@is.elta.co.il>
2001-11-30 7:18 ` Bug with watchpoints on Linux Pierre Muller
2001-11-21 16:19 ` Pierre Muller
2001-11-21 16:50 ` Eli Zaretskii
2001-11-21 17:07 ` [RFC] Possible bug with i386 watchpoints on several targets Pierre Muller
2001-11-30 8:06 ` Pierre Muller
2001-11-30 11:48 ` Eli Zaretskii
2001-11-23 6:39 ` Eli Zaretskii
2001-12-03 1:33 ` Pierre Muller
2001-12-03 3:10 ` Eli Zaretskii
2001-12-04 4:09 ` Pierre Muller
2001-12-04 23:50 ` Eli Zaretskii
2001-12-05 1:31 ` Pierre Muller
2001-12-05 3:23 ` Eli Zaretskii
2001-12-05 3:55 ` Pierre Muller [this message]
2001-11-30 7:45 ` 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.20011205123616.00a477a8@ics.u-strasbg.fr \
--to=muller@cerbere.u-strasbg.fr \
--cc=eliz@is.elta.co.il \
--cc=gdb-patches@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