This is the mail archive of the gdb-patches@sourceware.org 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] |
Other format: | [Raw text] |
I plan on eventually adding a third option to GenerateConsoleCtrlEvent and DebugBreakProcess, that injects a thread into the debuggee, since WinCE doesn't have any of the above. That should make every stoppable process stoppable, in all Windows versions.
Do you find appropriate to use this method?
It is exactly what DebugBreakProcess does internally, so if you have a problem with the approach, you shouldn't be using it :) The thread is short-lived. It is something like:
Well so it seems. :-) GenerateConsoleCtrlEvent seems to create a remote thread too.
1) May be solved by doing:
1. Create in gdbserver process as much threads as number of cpus -1 the computer has. These threads should consume all scheduled cpu for them.
2. SetPriorityClass on gdbserver process with real-time priority.
3. GetPriorityClass on child and store it to restore later on.
4. SetPriorityClass on child with below normal or idle.
5. Suspend all child threads.
Child should be stopped here.
Only problem I see with this can be if child changes its own priority class between steps 3 and 4 above, however this is a very remote possibility, because if this happens it is because child is already running in real-time priority, and in this case gdbserver possibly may not even work at all (unless you run gdbserver itself with this priority).
What do you think about this?
I was leaving something like this as a last resort, but should be possible,
I guess. Would need extra logic to handle the fact that there isn't
any real breakpoint exception live (in resume, for instance).
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |