From: Pierre Muller <muller@ics.u-strasbg.fr>
To: Mark Kettenis <kettenis@chello.nl>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Resend: [RFA] Fix problem with i386 watchpoints after restarting
Date: Thu, 04 Jul 2002 06:45:00 -0000 [thread overview]
Message-ID: <4.2.0.58.20020704143015.02832028@ics.u-strasbg.fr> (raw)
In-Reply-To: <4.2.0.58.20020617153258.00a45d18@ics.u-strasbg.fr>
At 15:35 17/06/2002 , Pierre Muller a écrit:
>At 12:16 13/06/2002 , Mark Kettenis a écrit:
> >Sorry, I somehow missed your earlier message. This seems to me as an
> >acceptable way to solve the problem (although I still think there is
> >something wrong with GDB's mechanism of removing hardware breakpoints.
> >But: could you add the reason why this is needed to the comment.
> >Minor nit: Please end your sentences with a '.' and put two spaces
> >after it.
>OK, I slightly modifed the patch
>by adding a comment to i386-nat.c
>and correcting the comment in the nm-i386.h file.
>
>Can I check this in?
After getting approval by a private mail, I have
checked this in.
Mark suggested that I should add a test case for
that bug, but I never really looked at the testsuite ...
And it does not work on cygwin target...
The following simple test can be added :
>>>Start of watchpoint_restart check >>>>
int x;
int
main ()
{
x = 1;
x= 2;
return 0;
}
>>>Start of watchpoint_restart check >>>>
The test would then simply consist of
1) compiling the source above.
2) starting gdb with the produced executable.
3) set a watchpoint on x variable.
4) start program with 'run'
5) We should get a stop because watchpoint x was hit (value changed from 0 to 1)
6) 'continue'
7) we should get a second watchpoint when x changes from 1 back to 2.
8)'continue'
9) we should get to end of execution.
10) start with 'run' again.
11) to 15) same as 5) to 9)
16) exit test.
By modifing the source only slightly, we could also check for
the other watchpoint bug that I reported and sent a patch for:
see http://sources.redhat.com/ml/gdb-patches/2002-06/msg00394.html)
I didn't get any answer about that RFA yet
>>>Start of watchpoint_restart check >>>>
int x;
int
main ()
{
x = 1;
x= 2;
x = 1;
return 0;
}
>>>Start of watchpoint_restart check >>>>
compile this program statically you will see that
at second run only the x=2 is hit currently
because the last value of previous run is
kept in the val field of the breakpoint structure.
If compiling normally the problem is hidden because the startup value of x is
reloaded at the time the dynamic libraries are loaded.
(This also means that you will never see that bug on win32 target as
DLLs are always loaded there!)
>2002-06-17 Pierre Muller <muller@ics.u-strasbg.fr>
>
> * i386-nat.c (child_post_startup_inferior): New function
> calling i386_cleanup_dregs if
> I386_USE_GENERIC_WATCHPOINTS is defined.
> * config/i386/nm-i386.h: define CHILD_POST_STARTUP_INFERIOR
> conditional to acknowledge that i386-nat.c has its
> own child_post_startup_inferior function.
>
>Index: i386-nat.c
>===================================================================
>RCS file: /cvs/src/src/gdb/i386-nat.c,v
>retrieving revision 1.4
>diff -r1.4 i386-nat.c
>232a233,240
> > /* Reset all debug registers at each new startup
> > to avoid missing watchpoints after restart. */
> > void
> > child_post_startup_inferior (ptid_t ptid)
> > {
> > i386_cleanup_dregs ();
> > }
> >
>Index: config/i386/nm-i386.h
>===================================================================
>RCS file: /cvs/src/src/gdb/config/i386/nm-i386.h,v
>retrieving revision 1.2
>diff -r1.2 nm-i386.h
>117a118,121
> > /* child_post_startup_inferior used to
> > reset all debug registers by calling i386_cleanup_dregs (). */
> > #define CHILD_POST_STARTUP_INFERIOR
> >
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:[~2002-07-04 13:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-13 0:20 Pierre Muller
2002-06-13 3:16 ` Mark Kettenis
2002-06-17 6:38 ` Pierre Muller
2002-07-04 6:45 ` Pierre Muller [this message]
2002-07-04 9:34 ` Daniel Jacobowitz
2002-07-04 9:37 ` Pierre Muller
2002-07-08 13:39 ` Andrew Cagney
2002-07-08 13:54 ` Mark Kettenis
2002-07-08 22:31 ` Eli Zaretskii
2002-07-09 1:40 ` Pierre Muller
2002-07-09 7:15 ` Pierre Muller
2002-07-09 7:50 ` Andrew Cagney
2002-07-09 8:34 ` Michal Ludvig
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.20020704143015.02832028@ics.u-strasbg.fr \
--to=muller@ics.u-strasbg.fr \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@chello.nl \
/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