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

[Lerele <lerele at champenstudios dot com>]

Pedro Alves wrote:

> Space around '?' and ':'.  Personally, I liked the res != FALSE ? 0 : 
> -1 version better.
>
>
> Honestly, I don't really care too much.
> You guys decide.
>
>
> I don't care much either, but I think the spaces around '?' and ':'
> are mandatory.
>
> +  return res ? 0 : -1;


I was wrong, res is not a Win32 BOOL, it's plainly a 0 or a 1.
Already fixed spacing, while you were uploading your patches.
I'll send a new version for interrupt patch when I get some time to do 
it, I'll need get latest cvs and merge my changes, then resend patch.



> +static void
> +win32_send_signal (int signo)
> +{
> +  if (signo == SIGINT)
>
>
> And I agree that it doesn't look right.  With my patch
> installed, it turns to:
>
> +static void
> +win32_send_signal (enum target_signal signo)
> +{
> +  if (signo == TARGET_SIGNAL_INT)
>
> Anyway, don't let this bother you.  If it gets OKed as is,
> I'll take care of it later.

I changed it to:

/* Send a signal to the inferior process, however is appropriate.  */
static void
win32_send_signal (int signo)
{
 if (target_signal_from_host (signo) == TARGET_SIGNAL_INT)
   {


I guess that would have been sufficient. But since you already changed 
"target->send_signal" to "target->send_interrupt" I guess that is no 
longer necessary.


> Hi all,
>
> This patch adds support for sending OUTPUT_DEBUG_STRING_EVENT
> messages to the controller gdb.  Compared to the version found in
> gdb/win32-nat.c, this handles Unicode messages, needed for
> WinCE, but will not handle the special cygwin signal markers. 


That was the next thing I was going to do for win32 low. Nicely done. 
Thanks. :-)


> Lerele wrote:
>
> > It works fine as it is, without making it too complex.
>
> Just tested it on Cygwin + XP Pro, and I could successfully stop a
> running process.  Nice.
>
> 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?
Isn't there any other way to do it on WinCE?

I say this because creating a single thread, either if you do it at 
child process creation, or at interrupt request, may make the child 
behave differently than when running it as a standalone (not being 
debugged). I mean, I don't know if this is really desired for gdbserver 
because doing this, memory layout for child may change, and when I debug 
a process that is buggy, say it crashes or whatever, I expect that when 
I debug the process, it will behave exactly the same way as when I run 
it without it being debugged, or at least as close as possible. A single 
memory allocation *may* affect a buggy child behavior and bypass the 
looked-for bug.

As an alternative, may I suggest maybe doing a simple PauseThread for 
all threads in child?
Win32 low already has synthetic thread pausing support and maybe this 
could be a fair solution.
This would involve tricking gdb to think a real Win32 debug exception 
has occured, and control that situation within win32 low exclusively.
The only problems I see with this is that 1) a child may suspend/resume 
threads (even though win32 docs say those functions are for debugger 
mainly), and this could interfere with stop procedure. 2) May affect 
timing, but anyway this already is affected by just running the child in 
multiprocess environment.

2) I guess is not really a problem.
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?
Does WinCE API have these required functions?
It may seem a quite odd way of doing it, but if it works, that's what 
counts I think.

Leo.