simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Simulavr-devel] GDB to stdin connection & threading


From: Petr Hluzín
Subject: [Simulavr-devel] GDB to stdin connection & threading
Date: Sun, 29 Jan 2012 20:54:32 +0100

Hi folks

Currently if user wants to use GDB, then he has to use command like
"target remote:1234" and "simulavr --gdbserver -p 1234". This some
disadvantages:
* personal firewalls will complain about the listening port
* attackers on network are able to abuse the poor simulavr
* automated scripts launching a simulavr have to be specially written
to not fail when a simulavr is already running
** if they are not, then they will get blocked without any diagnostic

So I am trying to allow launching simulavr by using GDB command
"target remote | simulavr.exe --something". (The existing ways will
remain available.)

The problem is this: GDB uses anonymous pipes for this command and
Windows does not allow asynchronous operation on anonymous pipes [1].
This means that simulavr would not be able to process inputs from
other TCP connections, e.g. fake terminal, the display thing (I do not
use it, I do not know). The problem exists because/if want to support
waiting for some external input and not be executing instructions at
the same time. (It took me several weekends of banging head against a
wall before realizing it cannot be done by any conventional means.)

Possible solutions:
A: Wait until Microsoft fixes anonymous pipes.
B: Wait until GDB switches to named pipes.
C: Use single-purpose thread in simulavr which would block on the
input from GDB.
D: Polling.
E: Something else which I missed.

I suggest to use the thread. Approaches A,B, C require some shuffling
in the code, basically all communication-capable classes would put
event objects (Windows) or file descriptors (Unixes) to a central
location which would do WaitForMultipleObjects() or select() on them.

Ideas? Objections?

The pipe problem does not exist on Linux, the thread would not be used on Linux.

[1] http://msdn.microsoft.com/en-us/library/aa365141.aspx

-- 
Petr Hluzin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]