Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: muller@cerbere.u-strasbg.fr
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC/RFA] Add hardware watchpoint support for cygwin target.
Date: Wed, 28 Nov 2001 13:55:00 -0000	[thread overview]
Message-ID: <3.0.6.32.20011128230438.00b31190@ics.u-strasbg.fr> (raw)
In-Reply-To: <8011-Wed28Nov2001201312+0200-eliz@is.elta.co.il>

At 20:13 28/11/01 +0200, Eli Zaretskii wrote:
>> Date: Wed, 28 Nov 2001 18:44:44 +0100
>> From: Pierre Muller <muller@cerbere.u-strasbg.fr>
>> 
>> But te are some annoying things,
>> the most annoying is that an exception seems to be generated
>> on read access of the watched area even if you only set a normal
>> watchpoint (which should use a write-only debug feature).
>
>So you are saying that watch, rwatch, and awatch all yield the same
>behavior?
>
>Are you sure that you pass the watchpoint information correctly to
>the OS?  For example, is the format of DR7 as the OS wants it
>identical to what GDB uses?  The layout of bits in dr_control_mirror
>follows Intel documentation, but the OS might want those bits in a
>different format (that's what the corresponding DPMI call does, for
>example).  I don't have Windows docs, so I cannot check this.

There is nothing available, (or at least I didn't find anything)
about i386 debug registers for the win32 API.
If you look at my patch, you will see that I simply do a straight
copy of the content of the i386-nat mirror registers into 
the DrX registers of the CONTEXT structure.
 
>> > /* Get the value of the DR6 debug status register from the inferior.
>> >    Here we just return the value stored in D_REGS, as we've got it
>> >    from the last go32_wait call.  */
>
>I believe you didn't really mean ``go32_wait'' here ;-)

 Yes, as you probably noticed... it directly taken from the go32-nat code...
I will fix this!

 Concerning Christopher's worry as to 
if this is a bug in the implementation or
in the OS handling, I have no idea, and its the reason
of the RFC...
  After some debugging, I think that the problem
arrises at some hidden stops (causes by events like DLL loading)
that do call to new_symfile_objfile,
that does call breakpoint_re_set
that finally calls breakpoint_re_set_one for each enabled
break or watch point.
And here appears the unwanted GDB message...

Does this mean that uiout should be temporarily redirected toward nul device
as is already done for other functions within cygwin native code?
Or should it really be considered as an error in breakpoint...


WARNING: multiple messages have this Message-ID
From: muller@cerbere.u-strasbg.fr
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC/RFA] Add hardware watchpoint support for cygwin target.
Date: Sat, 17 Nov 2001 21:08:00 -0000	[thread overview]
Message-ID: <3.0.6.32.20011128230438.00b31190@ics.u-strasbg.fr> (raw)
Message-ID: <20011117210800.VIleCmJml6Vim8_lHuGYqmOq_saqkzgOasuvJvM8nLQ@z> (raw)
In-Reply-To: <8011-Wed28Nov2001201312+0200-eliz@is.elta.co.il>

At 20:13 28/11/01 +0200, Eli Zaretskii wrote:
>> Date: Wed, 28 Nov 2001 18:44:44 +0100
>> From: Pierre Muller <muller@cerbere.u-strasbg.fr>
>> 
>> But te are some annoying things,
>> the most annoying is that an exception seems to be generated
>> on read access of the watched area even if you only set a normal
>> watchpoint (which should use a write-only debug feature).
>
>So you are saying that watch, rwatch, and awatch all yield the same
>behavior?
>
>Are you sure that you pass the watchpoint information correctly to
>the OS?  For example, is the format of DR7 as the OS wants it
>identical to what GDB uses?  The layout of bits in dr_control_mirror
>follows Intel documentation, but the OS might want those bits in a
>different format (that's what the corresponding DPMI call does, for
>example).  I don't have Windows docs, so I cannot check this.

There is nothing available, (or at least I didn't find anything)
about i386 debug registers for the win32 API.
If you look at my patch, you will see that I simply do a straight
copy of the content of the i386-nat mirror registers into 
the DrX registers of the CONTEXT structure.
 
>> > /* Get the value of the DR6 debug status register from the inferior.
>> >    Here we just return the value stored in D_REGS, as we've got it
>> >    from the last go32_wait call.  */
>
>I believe you didn't really mean ``go32_wait'' here ;-)

 Yes, as you probably noticed... it directly taken from the go32-nat code...
I will fix this!

 Concerning Christopher's worry as to 
if this is a bug in the implementation or
in the OS handling, I have no idea, and its the reason
of the RFC...
  After some debugging, I think that the problem
arrises at some hidden stops (causes by events like DLL loading)
that do call to new_symfile_objfile,
that does call breakpoint_re_set
that finally calls breakpoint_re_set_one for each enabled
break or watch point.
And here appears the unwanted GDB message...

Does this mean that uiout should be temporarily redirected toward nul device
as is already done for other functions within cygwin native code?
Or should it really be considered as an error in breakpoint...


  parent reply	other threads:[~2001-11-28 13:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-17 10:47 Pierre Muller
2001-11-28  9:44 ` Pierre Muller
2001-11-28 10:13 ` Eli Zaretskii
2001-11-17 16:07   ` Eli Zaretskii
2001-11-17 20:21   ` Christopher Faylor
2001-11-17 22:30     ` muller
2001-11-17 23:01       ` Christopher Faylor
2001-11-28 17:27         ` Christopher Faylor
2001-11-28 14:31       ` muller
2001-11-19  8:29     ` Eli Zaretskii
2001-11-21 15:15       ` Pierre Muller
2001-11-21 23:08         ` Christopher Faylor
2001-11-30  9:04           ` Christopher Faylor
2001-11-30  7:11         ` Pierre Muller
2001-11-29  0:12       ` Eli Zaretskii
2001-11-29  0:26       ` Pierre Muller
2001-11-19 11:30         ` Pierre Muller
2001-11-28 11:30     ` Christopher Faylor
2001-12-06  0:37     ` Pierre Muller
2001-12-06 13:30       ` Andrew Cagney
2001-12-07 16:59       ` Christopher Faylor
2001-12-10  2:23         ` Pierre Muller
2001-12-10 11:33           ` Christopher Faylor
2001-12-11  0:15             ` Eli Zaretskii
2001-12-11  1:04               ` Pierre Muller
2001-11-28 13:55   ` muller [this message]
2001-11-17 21:08     ` muller

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=3.0.6.32.20011128230438.00b31190@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