Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* RFC: gdbserver crash on win XP during watchpoint removal
@ 2014-10-14 18:46 Joel Brobecker
  2014-10-14 19:23 ` Pedro Alves
  0 siblings, 1 reply; 6+ messages in thread
From: Joel Brobecker @ 2014-10-14 18:46 UTC (permalink / raw)
  To: gdb-patches

Hello,

I started investigating an issue that seems to only show up on Windows
XP, and only when debugging via GDBserver. I used the following code,
which matches the code in testsuite/gdb.ada/int_deref:

    with Pck;

    procedure Foo is
    begin
       Pck.Watch := Pck.Watch + 1;
    end Foo;

The test just breaks on line 5, just before the increment, inserts
a watchhpoint on it, and then continues:

    (gdb) b foo.adb:5
    Breakpoint 1 at 0x4017c2: file foo.adb, line 5.
    (gdb) cont
    Continuing.

    Breakpoint 1, foo () at foo.adb:5
    5          Pck.Watch := Pck.Watch + 1;
    (gdb) watch watch
    Hardware watchpoint 2: watch
    (gdb) c
    Continuing.
    Remote communication error.  Target disconnected.: Invalid argument.

The immediate cause for the communication error is easily explained,
gdbserver crashes due to a failed assertion:

    x86_remove_aligned_watchpoint: Assertion `state->dr_control_mirror == 0' failed.

I think the assertion might be invalid, in this case. Turning debug
register traces on, I see:

insert_watchpoint (addr=000000000041c010, len=4, type=data-write):
        CONTROL (DR7): 00000000000d0101          STATUS (DR6): 0000000000000000
        DR0: addr=0x0041c010, ref.count=1  DR1: addr=0x00000000, ref.count=0
        DR2: addr=0x00000000, ref.count=0  DR3: addr=0x00000000, ref.count=0
stopped_data_addr:
        CONTROL (DR7): 00000000000d0501          STATUS (DR6): 00000000ffff4ff0
        DR0: addr=0x0041c010, ref.count=1  DR1: addr=0x00000000, ref.count=0
        DR2: addr=0x00000000, ref.count=0  DR3: addr=0x00000000, ref.count=0
watchpoint_hit (addr=000000000041c010, len=-1, type=data-write):
        CONTROL (DR7): 00000000000d0501          STATUS (DR6): 00000000ffff4ff1
        DR0: addr=0x0041c010, ref.count=1  DR1: addr=0x00000000, ref.count=0
        DR2: addr=0x00000000, ref.count=0  DR3: addr=0x00000000, ref.count=0
watchpoint_hit (addr=000000000041c010, len=-1, type=data-write):
        CONTROL (DR7): 00000000000d0501          STATUS (DR6): 00000000ffff4ff1
        DR0: addr=0x0041c010, ref.count=1  DR1: addr=0x00000000, ref.count=0
        DR2: addr=0x00000000, ref.count=0  DR3: addr=0x00000000, ref.count=0

What's interesting is the value of DR7, which suddenly gets an extra
0x400. So when we unset the bits we set before, we still that that
extra bit on the 10th bit.

But looking at Intel documentation I have (IA-32 Intel Architecture
Software Developer's Manual - Volume 3), it says that bits 12-11-10
are 001.

I'm tempted to either clear those bits when reading the register value,
or else to mask those bits in the assertion. I feel that masking
those bits would be cleaner, since we'd carry a register value which
better matches reality. But the fact that this is working elsewhere
makes me wonder if we might actually be relying elsewhere on those bits
being zero, or maybe at least assuming that they are.

Any thoughts before I send a patch?

Thanks!
-- 
Joel


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-10-15 19:02 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-14 18:46 RFC: gdbserver crash on win XP during watchpoint removal Joel Brobecker
2014-10-14 19:23 ` Pedro Alves
2014-10-14 21:37   ` Joel Brobecker
2014-10-15  0:38     ` Pedro Alves
2014-10-15 14:35       ` Joel Brobecker
2014-10-15 19:02         ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox