be changed in the future to "yes".
If MKDYNAMICROOT == "no", there is no change from existing behaviour
of a static /bin and /sbin (and a few programs in elsewhere).
If MKDYNAMICROOT == "yes", the following changes occur:
in <bsd.own.mk>:
SHLIBDIR?= /lib
SHLINKDIR?= /lib
in various Makefiles, the following entry is DISABLED.
LDSTATIC?=-static
This results in all programs (except those "standalone" programs built
in sys/arch/*/stand) are linked dynamically, the shared linker is moved
from /usr/libexec to /lib (with a compat symlink), and the shared
libraries used by /bin and /sbin programs are moved from /usr/lib to
/lib (with compat symlinks).
- For cleaner subprocess traces, malloc something before
spawning, so the syscalls malloc does while initializing don't gunk up
the trace.
- Increase pipe buffer sizes.
The child process of do_ktrace() does return and the stack is
changed by another function call (execvp()).
By using vfork() (my previous change), the execution of the parent
process resumes on the modified stack. Oops.
We could use vfork() carefully, but for now use fork().
Problem reported and investigated by Ethan Solomita <ethan@geocast.com>.
Thanks.
Following examples show the cases.
% ktrace -f - false >/dev/null && echo wrong
wrong
% ktrace -f - -i /usr/sbin/update >/dev/null
(does not return to command line)
That is, back out last change and restore the roles of parent/child for
ktrace(1). The ktruss(1) stuff still remains.
Yes, ktruss(1) has the problems. Better implementation is expected.
- fix command name in SYNOPSIS section of man page.
- link ktrace man page to ktruss man page.
- add executable and man page for ktruss in distrib sets.
1. If fork()ing, the program is executed twice.
2. If the ktruss(1) output is bufferd, the final output is not flushed
(because it is executing).
% ktrace -f - rm >/dev/null
usage: rm [-dfiPRrW] file ...
usage: rm [-dfiPRrW] file ...
% ktruss date | cat
Fri Jul 23 12:09:45 JST 1999
Fri Jul 23 12:09:46 JST 1999
%
lukem