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