From: Lerele <lerele@champenstudios.com>
To: Pedro Alves <pedro_alves@portugalmail.pt>
Cc: gdb-patches@sourceware.org
Subject: Re: [Patch] Win32 gdbserver new interrupt support, and attach to process fix.
Date: Sun, 04 Mar 2007 22:53:00 -0000 [thread overview]
Message-ID: <45EB4D5A.7070703@champenstudios.com> (raw)
In-Reply-To: <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.
next prev parent reply other threads:[~2007-03-04 22:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-23 23:52 Lerele
2007-02-24 12:07 ` Eli Zaretskii
2007-02-24 13:03 ` Lerele
2007-02-24 14:07 ` Eli Zaretskii
2007-02-24 15:23 ` Lerele
2007-02-24 19:10 ` Eli Zaretskii
2007-02-24 21:19 ` Pedro Alves
2007-02-24 21:44 ` Andreas Schwab
2007-02-24 23:35 ` Lerele
2007-02-25 0:15 ` Daniel Jacobowitz
2007-02-25 1:57 ` Pedro Alves
2007-02-25 22:46 ` Pedro Alves
2007-03-04 22:53 ` Lerele [this message]
2007-03-05 0:56 ` Pedro Alves
2007-03-05 1:21 ` Pedro Alves
2007-03-05 13:17 ` Lerele
2007-03-05 20:34 ` Lerele
2007-03-05 20:44 ` Pedro Alves
2007-03-06 0:04 ` Pedro Alves
2007-03-06 20:39 ` Pedro Alves
2007-03-06 22:18 ` Lerele
2007-03-06 23:22 ` Pedro Alves
2007-03-05 12:44 ` Daniel Jacobowitz
2007-03-05 20:30 ` Lerele
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45EB4D5A.7070703@champenstudios.com \
--to=lerele@champenstudios.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro_alves@portugalmail.pt \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox