This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATH RFA] Avoid Cannot read 0x20000000 on cygwin GDB
On Tue, Sep 12, 2000 at 05:55:37PM +0200, Pierre Muller wrote:
>>>PPS: I am currently writing hardware watchpoint support for Cygwin via Page
>>>protections,
>>>it basically works except that I get troubles when the page protection is
>>>triggered inside a system DLL code.
>>
>>Couldn't you kludge this by not allowing hardware points on sections of code
>>in a system DLL as determined by whether the DLL path includes the windows
>>system directory? I do something similar for the cygwin DLL.
>
> The problem is that if a page protection error happens in normal code,
>and that the address is not a watchpoint, the page protection is
>removed, a single step is made and the page protection is turned on again.
>
> If the same happens inside a system call
>(I suspect any DLL loaded a address above 0x8000000)
>then single step setting by changing the trace bit does not work !
>Setting a breakpoint inside system DLL probably also will not work
>(I must confess that I didn't even try!)
I don't see why this wouldn't work. Windows should use copy-on-write to set
the breakpoint just like it does for the executable image. I've single
stepped into system DLLs before.
>So, I simply try to go up the stack and I palce a breakpoint at the first
>return address that is in normal code.
>This will miss any further watchpoint at the same page... but nothing is
>never perfect :(
>Furthermore, for the moment, my code fails if a second page protection
>fault is
>triggered before reaching the breakpoint set.
This is somewhat similar to the way that signals are now handled in cygwin.
For a while I just looked for anything loaded above 0x8000000 but that
wasn't general purpose enough. So, I had to figure out if the program
had received the signal while in a system DLL by keeping track of the
memory occupied by system DLLs.
This is a little easier to do in the process which has loaded the DLLs than
it is in the debugger but I think it is still doable in the debugger.
>>Hardware watchpoints would be much appreciated.
>>
>>Actually, someone else working on the win32-nat.c stuff is much appreciated!
>
> I was tired of not being able to watch variables with win32 GDB !!
Ditto.
cgf