From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23823 invoked by alias); 9 Feb 2005 14:39:51 -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 23289 invoked from network); 9 Feb 2005 14:39:43 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Feb 2005 14:39:43 -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 j19Edhud000340 for ; Wed, 9 Feb 2005 09:39:43 -0500 Received: from localhost.redhat.com (vpn50-64.rdu.redhat.com [172.16.50.64]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j19EdhO04638; Wed, 9 Feb 2005 09:39:43 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C9F7C7D79; Wed, 9 Feb 2005 09:39:06 -0500 (EST) Message-ID: <420A2088.8080409@gnu.org> Date: Wed, 09 Feb 2005 16:46: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: <200501131211.j0DCBhLc008048@ignucius.se.axis.com> In-Reply-To: <200501131211.j0DCBhLc008048@ignucius.se.axis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00054.txt.bz2 Hans-Peter Nilsson wrote: >>Date: Tue, 11 Jan 2005 10:07:52 -0500 >>From: Andrew Cagney > > >>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