Re: sim/common: pipe syscall support

[Andrew Cagney <cagney@gnu.org>]

Hans-Peter Nilsson wrote:
> The pipe support is a bit limited and requires that your
> simulator has support for multiple same-memory-space contexts to
> be useful.  The pipe syscall is (besides other uses) the
> LinuxThreads method for synchronization and message passing
> between threads: supporting pipes is necessary for running
> programs compiled with -pthread, pre-NPTL.  The patch is
> relative (depends textually on) all my previous sim patches.
> (Beware, manually edited patch in an atempt to avoid including
> them.)
> 
> Regarding the data structures, AFAICS the pipe stuff should not
> cause problems for a future dup syscall implemented by keeping
> track of the dups through cb->fd_buddy[], which seems to have
> been a major goal for it.
> 
> The callbacks are supposed to be used to tell the
> target-specific simulator parts that the current context needs
> to to wait for syscall completion or that the context for the
> "other" end of a pipe may continue.
> 
> If there's a simulated target with a sizeof int not being 4
> (including padding at higher address) and wanting to use the
> pipe syscall, it should adjust the cb->target_sizeof_int member
> at the time of its sim_open call.
> 
> Test-cases for the CRIS simulator cover every execution path.
> Besides cris-elf, I built simulators to arm-elf frv-elf
> h8300-elf m32r-elf m68hc11-elf mcore-elf mips-elf mn10300-elf
> powerpc-elf and v850-elf as a rudimentary test on
> i686-pc-linux-gnu and to frv-elf, mn10300-elf and cris-elf on
> sparc-sun-solaris2.7 using gcc-2.95.3.
> 
> (Correct, I did not exclude any targets that were mentioned to
> be broken wrt. gdb.  I don't think that's a valid reason to skip
> them.  The simulators do not directly depend on the state of gdb
> and are used elsewhere, by e.g. gcc cross testing.  See
> <URL:http://gcc.gnu.org/simtest-howto.html>.)
> 
> Ok to commit?
> 
> include/gdb:
> 	* callback.h (struct host_callback_struct): New members pipe,
> 	pipe_empty, pipe_nonempty, ispipe, pipe_buffer and
> 	target_sizeof_int.
> 	(CB_SYS_pipe): New macro.
> 
> sim/common:
> 	* syscall.c (cb_syscall) <case CB_SYS_pipe>: New case.
> 	* callback.c [HAVE_LIMITS_H]: Include limits.h.
>   	Include libiberty.h.
> 	(os_close, os_read, os_write, os_fstat, os_ftruncate): Support fd
> 	being either end of a pipe.
> 	(os_pipe, os_pipe_empty, os_pipe_nonempty): New functions.
> 	(os_shutdown): Clear pipe state.
> 	(default_callback): Initialize new members.

Ok (this does feel very low level).

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.

Also, think about how this will work when (yes you can laugh) GDB 
becomes properly event driven (or failing that multi-threaded).

Andrew