This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [Patch] Win32 gdbserver new interrupt support, and attach to process fix.
- From: Lerele <lerele at champenstudios dot com>
- To: Pedro Alves <pedro_alves at portugalmail dot pt>
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 04 Mar 2007 23:51:06 +0100
- Subject: Re: [Patch] Win32 gdbserver new interrupt support, and attach to process fix.
- References: <45DF7E27.10102@champenstudios.com> <45E211A5.6080905@portugalmail.pt>
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.