sim/common: pipe syscall support
Andrew Cagney
cagney@gnu.org
Wed Feb 9 16:46:00 GMT 2005
Hans-Peter Nilsson wrote:
>>Date: Tue, 11 Jan 2005 10:07:52 -0500
>>From: Andrew Cagney <cagney@gnu.org>
>
>
>>Ok (this does feel very low level).
>
>
> Thanks.
>
>
>>However, can you also look over the remote file i/o code. For reasons
>>of stupidity we've ended up with two slabs of code (remote hosted i/o
>>and simulator hosted i/o) doing essentially the same thing.
>
>
> I am at a loss here: I cannot perform any useful audit here
> compared to the simulator I/O. I looked for a while and grepped
> through the manual, but couldn't understand how the bits are
> connected, so I have to leave that to a real gdb maintainer. At
> least it seems as if calls to remote-fileio doesn't end up in
> the simulator and so doesn't interfere with pipe support there;
> it connects to a the remote packet handler. The remote-fileio
> (whatever it's used for?) seems very simple, only the most basic
> operations are there and it doesn't immediately seem a candidate
> for adding pipe functionality.
I'm talking more generally.
The simulator (common/), the GDB-sim interface (remote-sim.c:gdb_os*)
and remote (remote-fileio.*) all implement the "hosted file I/O"
feature. Each though has its own private implementation :-( That's
triplication which strongly suggests a hosted file-io library (sim/io/*?).
>>Also, think about how this will work when (yes you can laugh) GDB
>>becomes properly event driven (or failing that multi-threaded).
>
>
> The simulator vs. gdb interface would have to get thread
> support. It doesn't seem like there are framework bits at the
> moment.
Right.
Andrew
More information about the Gdb-patches
mailing list