This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Cygwin native watchpoint limitations.
- From: Pierre Muller <muller at ics dot u-strasbg dot fr>
- To: gdb-patches at sources dot redhat dot com
- Cc: Christopher Faylor <cgf at redhat dot com>
- Date: Wed, 10 Jul 2002 16:58:56 +0200
- Subject: Cygwin native watchpoint limitations.
After a long research I finally think
that I understood more or less what is going on
the following problem:
Try to compile any C program with -mno-cygwin option
(this is required for the bug to show up!)
Set a global watchpoint on a variable that is changed in the
program and run the program.
=> You don't get any watchpoint hits when the program should stop.
I believe that the reason is that the
debug register modification is not working completely
as I first thought it was:
it really seems that setting the debug register in the startup code fails,
this is probably done that way by the OS for some reason,
and we can't do much about it, but we can try to still get the watchpoints to work correctly
by adding an invisible breakpoint at lpStartAddress of
the CREATE_PROCESS_DEBUG_INFO
or at the value return by bfd_get_start_address function.
First question: -- which one of these two should I choose?
Second question: how am I supposed to add this "internal" breakpoint?
There is no real need to stop at that breakpoint,
removing the breakpoint and continuing is just enough to get the
values of the debug registers to be set correctly.
But I don't know really how I should do that cleanly...
Using commands_command function is not possible for
setting a 'cont' command.
Should I rather try using the create_internal_breakpoint
or set_rawx_breakpoint functions?
Note, it might be required to do the same for starting threads .
Note, the bug described above does not show up for cygwin compiled
files because these executable generate several debug events at startup
(exception haandler thread creation, debugging string output,
loading of cygwin1.dll) one of these must allow the debug registers to be set correctly.
Another even more general restrictin to the debug register usage is that those
watched areas are not active inside the kernel itself.
if you try for instance to watch thread_head.next.context.Eip you will never get any hit inside
GetThreadContext function....
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