passed to the execl(), execle(), and execlp() functions are in the form
of the argument vector to be passed to execve(). On these architectures,
it is unnecessary to count the number of arguments, allocate space on
the stack, copy the arguments, etc. The vector already on the stack
can be used instead.
When some arguments are passed in registers (like most RISC CPU's), it
should be possible to allocate stack space adjacent such that the
registers can be copied to that memory. After that, the same
approach described above can be used.
This change takes advantage of this on the i386, m68k, and ns32k. It
is probably true on the vax, but I am unable to check. RISC CPU's
probably need assembly language implementations to ensure everything
is placed exactly as needed when registers are copied to the stack...
> Prevent recursive invocation of mcount() while in kernel by setting profiling
> state to BUSY while in mcount(). This allows profiling to work when mcount()
> calls a profiled routine (for example, udiv on the SPARC).
never forwarded to me :-(.
> Clean up the FP stack before returning. The i387 exp() leaked an FP
> register on its first call. Subsequent calls reused the register so
> the leak didn't accumulate.
dump is present. This was caused by the fact that kvm_dump_mkheader() was
called *before* savecore checks the dump magic and kvm_dump_mkheader() returned
-1 without setting an error message. The latter is fixed now.
output emit newlines and those that return a pointer to string do not
append them.
The existing behavior was inherited from RPC4.0, but this seems to have
been corrected sometime before SunOS 4.1.
The documentation has been updated to reflect the new behavior.
xdr_ypbind_setdom() would always fail because the test for
xdr_ypdomain_wrap_string() was reversed. Fixed this and in
the process made all the function tests to be of the form:
if (!xdr_foo())
return FALSE;
....
return TRUE;
instead of having some of them like above and others like:
if (xdr_foo() == FALSE)
return FALSE;
...
return xdr_bar();
this is more consistant now and hopefully in the future people
will pattern match correctly and not introduce spurious errors.
using HASHFRACTION directly. in time-critical calculations, if HASHFRACTION
is a power of two, check that p->hashfraction == HASHFRACTION and if so do
the calculation with the compiled-in value so that the compiler can optimize
out (potentially) expensive divisions. if p->hashfraction != HASHFRACTION,
actually do the division. This has the result that on machines with slow
division, the division can be optimized out of the common case, but that
if HASHFRACTION changes from the compiled-in value (for whatever reason),
profiling will still work. Changes suggested by Chris Torek.
undefined behavior (so we can do whatever we want) while the latter
doesn't happen much in actual practice.
These changes make these functions considerably smaller and faster.
