From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31778 invoked by alias); 11 Jan 2005 15:09:53 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30476 invoked from network); 11 Jan 2005 15:09:15 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Jan 2005 15:09:15 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0BF9AnG030829 for ; Tue, 11 Jan 2005 10:09:10 -0500 Received: from localhost.redhat.com (vpn50-45.rdu.redhat.com [172.16.50.45]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0BF99r05950; Tue, 11 Jan 2005 10:09:10 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B2EFC7D79; Tue, 11 Jan 2005 10:07:53 -0500 (EST) Message-ID: <41E3EBC8.3060204@gnu.org> Date: Tue, 11 Jan 2005 15:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Hans-Peter Nilsson Cc: gdb-patches@sources.redhat.com Subject: Re: sim/common: pipe syscall support References: <200412150538.iBF5cXkF015923@ignucius.se.axis.com> In-Reply-To: <200412150538.iBF5cXkF015923@ignucius.se.axis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00070.txt.bz2 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 > .) > > 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) : 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