Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Aravinda <aravindakidambi@gmail.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb@sourceware.org
Subject: Re: Problem with manual watchpoints
Date: Mon, 28 Dec 2009 21:22:00 -0000	[thread overview]
Message-ID: <26eb53620912281321k3fe1ee7dy9fcdc8bdff69cd4b@mail.gmail.com> (raw)
In-Reply-To: <20091224215217.GA32721@host0.dyn.jankratochvil.net>

Hi Jan,

Thanks again for the reply. When I tried with -O0, i found that, the
same program got the breakpoint exception. But there were also times
when it just ran to completion too. I then went back to the -O2 and
ran the compiled program several times and found that, even with -O2,
the breakpoint exception occurs sometimes and does not occur at other
times.

Reading about debug registers and breakpoint exception, I came across this
"When using data breakpoints it is recommended that either the LE or
GE bit of DR7 be set also. If either LE or GE is set, any data
breakpoint trap is reported exactly after completion of the
instruction that accessed the specified memory item. This exact
reporting is accomplished by forcing the 80386 execution unit to wait
for completion of data operand transfers before beginning execution of
the next instruction. If neither GE nor LE is set, data breakpoints
may not be reported until one instruction after the data is accessed
or may not be reported at all."

Which means, Im just having some trouble with exact reporting of the
exception I guess. Inspite of having both LE and GE set, the behaviour
is random. Could it be possible for a processor with debug registers
to not support exact reporting or could there be problems since Im
working on a VM ?

Thanks,
Aravinda

On Thu, Dec 24, 2009 at 4:52 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Thu, 24 Dec 2009 22:41:37 +0100, Aravinda wrote:
>> Yes, thats why I have a watchpoint added at &a[20]. So on accessing
>> the first element out of the allocated array, I want the program to
>> receive a SIGTRAP.
>
> Ah, OK.
>
>> Infact it gets this signal when the getc(stdin) is included, is it
>> something to do with the program should be in single step mode to get
>> SIGTRAPs
>
> No.
>
>> or is the loop way too simple that it executes in no time before the SIGTRAP
>> is even raised ?
>
> There may be some compiler optimization in effect such as if you have not used
> "volatile" keyword for the "a" array. You should rather check the code using
> "objdump -dS" or GDB "disass/m" how it got compiled.
>
> Still (with default -O0) I do not know the answer.
>
>
> Regards,
> Jan
>


  reply	other threads:[~2009-12-28 21:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-24 20:47 Aravinda
2009-12-24 21:08 ` Jan Kratochvil
2009-12-24 21:42   ` Aravinda
2009-12-24 21:52     ` Jan Kratochvil
2009-12-28 21:22       ` Aravinda [this message]
2009-12-28 21:49         ` Jan Kratochvil
2009-12-29  3:00           ` Aravinda

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=26eb53620912281321k3fe1ee7dy9fcdc8bdff69cd4b@mail.gmail.com \
    --to=aravindakidambi@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@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