Re: When submitting sim/cris: other sim improvements before or after?

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> Date: Mon, 15 Nov 2004 20:34:15 -0500
> From: Andrew Cagney <cagney@gnu.org>

> 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