This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]