[Patch] Win32 gdbserver new interrupt support, and attach to process fix.

[Lerele]

Pedro Alves wrote:

> Pedro Alves wrote:
>
>> What do you think of just suspending of thread, and setting a breakpoint
>> at the current PC, and resuming?
>>
>
> Errrh, don't even bother to answer this question.  This method is of 
> course very
> fallible. The thread may be blocked on IO or on a synchronization 
> object, which is
> common in windows code (waiting for events).  If the thread doesn't 
> get scheduled,
> the breakpoint won't be hit.  There may not be any thread that is a 
> got candidate
> for the breakpoint - like if you have all your threads either deadlock 
> or blocked.
> The beauty of injecting a remote thread, is that it stops all the 
> inferior threads atomically,
> with minimum interference.  That leaves:
>
Sorry for delay.
Also there's the problem you said on WinCE about not being able to write 
memory (flash/rom...)

> - ctrl-c event, which in some cases doesn't get through.
> - DebugBreakProcess, on XP and 2003 Server and emulating it on NT < 5 
> / Win9x/ME / CE
>  using code injection. One case where it could disturb the inferior 
> would be
>  when you can't debug a DllMain because of the CREATE_THREAD_EVENT that
>  this generates, or is there a way to inhibit its propagation?
> - 'suspend all threads manually, but no breakpoint' method.
>
I'd just leave the last option.
That's according with my personal preferences, for all advantages I 
wroite in previous messages.
Does WinCe have available Set/GetPriorityClass, SetProcessAffinityMask, 
SuspendThread, ResumeThread?
First two only work on some cases/win versions anyway.
However, gdb win32-nat is already done with first option if I remember 
right, so maybe there's a preference to keep it that way.
Also, about DllMain problem you say, I'd guess last option should also 
let you seamlessly debug DllMain without doing anything else (without 
having to disable breakpoints when doing an interrupt for instance 
--this would have to be done on client gdb side-- and even would 
introduce problems such as hitting a disabled-for-interrupt breakpoint 
when interrupt has not yet reached child).
I find last option better almost however you look at it, unless there's 
some other problem I'm not seeing... maybe having a trillion threads 
running or something?
Maybe writing down a pros/cons list could decide for itself.


>> What about using the version you sent (if approved), and then work on
>> this new version on top?  IMHO, it is better to have something working
>> first.  (I don't believe the extra thread makes a difference 
>> 99.999999999%
>> of the times.)
>
> This is still my opinion.
>
I agree. Keep working code, and work on other option(s).
Haven't had time to prepare the new patch. I hope I do will this week(end).