This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sim/common: pipe syscall support


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]