From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16321 invoked by alias); 16 Nov 2004 06:56:12 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16147 invoked from network); 16 Nov 2004 06:56:05 -0000 Received: from unknown (HELO krynn.se.axis.com) (212.209.10.221) by sourceware.org with SMTP; 16 Nov 2004 06:56:05 -0000 Received: from ignucius.se.axis.com (ignucius.se.axis.com [10.83.5.18]) by krynn.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id iAG6u1AD021942; Tue, 16 Nov 2004 07:56:01 +0100 Received: from ignucius.se.axis.com (localhost [127.0.0.1]) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) with ESMTP id iAG6u0dD002088; Tue, 16 Nov 2004 07:56:00 +0100 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id iAG6u0pr002084; Tue, 16 Nov 2004 07:56:00 +0100 Date: Tue, 16 Nov 2004 07:59:00 -0000 Message-Id: <200411160656.iAG6u0pr002084@ignucius.se.axis.com> From: Hans-Peter Nilsson To: cagney@gnu.org CC: hans-peter.nilsson@axis.com, gdb@sourceware.org In-reply-to: <41995917.3020304@gnu.org> (message from Andrew Cagney on Mon, 15 Nov 2004 20:34:15 -0500) Subject: Re: When submitting sim/cris: other sim improvements before or after? X-SW-Source: 2004-11/txt/msg00158.txt.bz2 > Date: Mon, 15 Nov 2004 20:34:15 -0500 > From: Andrew Cagney > Hans-Peter Nilsson wrote: > > I'd also like to submit two additional features: > > > > - New option --file-path-prefix=/where/ever. Prefix all > > syscalls with the supplied path and chdir to there upon program > > start. Chroot your simulated programs! (Half-baked that is; > > there's still a "..".) Changes are mostly in > > sim/common/callback.c, to all syscalls taking filename > > arguments. > > There's already --with-sysroot, how is this different? One is a run-time option, the other is a configure option. Do you mean that there should be a constant path compiled in? > Having the code > obey that, and have a --sysroot=... option (same name as GCC?) definitly > sound like a good idea. There's no option with the intended effect in GCC. There is a configure option and there is a preprocessor option -isysroot. (No link-time option besides the configure option.) If you want to call it "--sysroot=..." rather than "--file-path-prefix=...", sure, I don't really mind. Maybe there'll eventually be a GCC option, and it'd likely be called "--sysroot=..." or "-fsysroot=..." (the former non-f-convention is used in some recent options). > > - Pipe support. Well, not full support, just enough that it has > > been successfully used to emulate the glibc non-nptl > > linuxthreads (well-behaved pipe usage) and do some performance > > analysis on a reasonably large application using pthreads. To > > make any use of pipes, CPU-specific support to keep track of > > different CPU contexts is needed (but only one memory space of > > course). Changes are in sim/common/callback.c for all syscalls > > that have anything to do with file descriptors and a few extra > > fields in include/gdb/callback.h. > > By "pipe" you mean? See pipe(2) :-) A synchronization mechanism, usable for passing messages. In sim, writing to the write-end of a pipe causes the write to go to a buffer and a callback to be called, which port-specific code can hook into and use to switch context, so that the context switched to (another thread) can read from the read-end of the pipe. It is up to target-side code to implement blocking. Similar for the read-end; a read that empties the buffer of the pipe causes another callback to be called that the target code can hook into and switch context (to the original or yet another thread). All syscalls operating on fd:s need to add conditions that check if the fd is a pipe and DTRT (return error or read or write or fstat the pipe). For typical use, refer to glibc 2.2.4 (IIRC) non-nptl "linuxthreads". > > I'd like to submit these features before the actual CRIS port, > > because that'd simplify my work. > > Sounds like a good move, lets start with that. Status: I'm busy updating the CGEN port to the CGEN in CVS (a year and a half newer), so I can run my sim test-suite and add necessary tests for the new syscalls on the expect to be pristine sources and submit it together with the new code. (But more on the CGEN-specific things on the CGEN list once I know at which end each fault is, and how to fix them.) brgds, H-P