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

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

[Hans-Peter Nilsson]

Hi.

I'm in the progress of updating a local CGEN-based sim port for
CRIS and CRISv32 (a mostly-incompatible improved pipelined
variant) for submission to gdb.  The sim port aims to be useful
for GCC regression testing as well as debugging of GNU/Linux
statically linked binaries (lots of syscalls supported), but may
lack in integration with gdb.  (That is, I'm totally clueless as
to what is needed in that area.)

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.

- 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.

Some other changes worth noting:

- Syscall for lstat.

- Missing CB_SYS_rename case in common/syscall.c (though the
common/callback.c case is already in place).

- Ten more struct stat st_* fields supported in
cb_host_to_target_stat (just using the existing strncmp/store
machinery with no further host<->target mapping).

I'd like to submit these features before the actual CRIS port,
because that'd simplify my work.  There's also a ~500k
port-specific testsuite, both C tests (mostly to exercise
syscalls in a sane fashion) and assembler tests for the actual
CPU parts.  I'll accept responsibility as maintainer for this
sim port.  Copyright assignment papers for GDB are in place,
company-wide for Axis Communications.


Does the file-path-prefix and the pipe support sound acceptable?

Would you (as I) prefer to deal with the new features and
bug-fixes etc. before the actual port?

brgds, H-P

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

[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?  Having the code 
obey that, and have a --sysroot=... option (same name as GCC?) definitly 
sound like a good idea.

> - 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?

> Some other changes worth noting:
> 
> - Syscall for lstat.
> 
> - Missing CB_SYS_rename case in common/syscall.c (though the
> common/callback.c case is already in place).
> 
> - Ten more struct stat st_* fields supported in
> cb_host_to_target_stat (just using the existing strncmp/store
> machinery with no further host<->target mapping).
> 
> 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.

Andrew

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

[Hans-Peter Nilsson]

> 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