Rather than write out a table for each architecture, rely on the C
compiler to define _LP64 for 64-bit ones, on the assumption that
anything not LP64 is ILP32, and on CTASSERTs to verify this
assumption so that if it's wrong it'll fail safely with a noisy build
failure.
Gives zfs half a chance of building on, e.g., powerpc.
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
Comment here already says it isn't necessary and will be removed.
Hasten the process for us and avoid the problematic typedef.
This is useful because u_longlong_t would otherwise need to be
provided by compat headers.
Mark arguments to dtrace_probe_lookup() with __UNCONST().
The proper fix constifying it causes pollution of const in too many files.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Constify char* types when initialized with liternals.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Constify dgr_suffix.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Use __UNCONST() to remove const from an argument.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Add missing const keywords in dtrace_strncmp().
Initialize lim1 and lim2 to zero always. This prevents a false positive
about potentially unset but used variable.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Clang/LLVM does not recognize:
- -Wno-discarded-qualifiers
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Add missing const keywords.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Clang/LLVM does not recognize:
- -Wno-discarded-qualifiers
- -Wno-unused-but-set-variable
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Clang/LLVM does not recognize:
- -Wno-maybe-uninitialized
- -Wno-unused-but-set-variable
MKGCC=yes still builds the distribution.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
merge a new version of the CDDL dtrace and ZFS code.
this changes the upstream vendor from OpenSolaris to FreeBSD,
and this version is based on FreeBSD svn r315983.
in addition to the 10 years of improvements from upstream,
this version also has these NetBSD-specific enhancements:
- dtrace FBT probes can now be placed in kernel modules.
- ZFS now supports mmap().
this changes the upstream vendor from OpenSolaris to FreeBSD,
and this version is based on FreeBSD svn r315983.
in addition to the 10 years of improvements from upstream,
this version also has these NetBSD-specific enhancements:
- dtrace FBT probes can now be placed in kernel modules.
- ZFS now supports mmap().
While it fixed the problem of trailing spaces, but if the probe specifier
contained leading spaces, it would brake dtrace. The proper fix would be
to skip the leading spaces in the string as well.
However, it would result in a bigger diff for a very small benefit. While
a new import of dtrace is impending, it's better not to have this change.
Discussed with christos.
When using dtrace using one of the tracing options, such as -n, -P, -i, -f etc.,
the first line of output from dtrace one is something like this:
sudo dtrace -n 'syscall:::entry /pid == 100/ {@num[probefunc] = count();}'
dtrace: description 'syscall:::entry ' matched 482 probes
There is a trailing space at the end of the probe specifier name ('syscall:::entry ').
This happens beucase dtrace tries to separate the probe name from the predicate and actions
using `{' and `/' as the separators but doesn't consider space also as a possible separator.
Output after this change:
sudo dtrace -n 'syscall:::entry /pid == 100/ {@num[probefunc] = count();}'
dtrace: description 'syscall:::entry' matched 482 probes
ok christos@
VOP_RECLAIM naturally has exclusive access to the vnode, so having it
locked on entry is not strictly necessary -- but it means if there
are any final operations that must be done on the vnode, such as
ffs_update, requiring exclusive access to it, we can now kassert that
the vnode is locked in those operations.
We can't just have the caller release the last lock because some file
systems don't use genfs_lock, and require the vnode to remain valid
for VOP_UNLOCK to work, notably unionfs.
fix the dtrace "args" variable to return correct values.
simplify the invop handlers a bit by changing the second argument
from a pointer into the stack to a pointer to the trapframe.
rather than including in kernels with KDTRACE_HOOKS defined. Update
the dtrace_fbt module to depend on the zlib module.
Bump kernel version to avoid module mismatch.
Welcome to 7.99.38 !
Fix DTrace's panic() action.
It would previously call into some unfinished Solaris compatibility code
and return without actually calling panic(9). The compatibility code is
unneeded, however, so just remove it and have dtrace_panic() call vpanic(9)
directly.
Fixes immediate problem in PR-51265. However, this now reveals another
redefined symbol 'strpbrk' in the required module "solaris".
[1] https://svnweb.freebsd.org/changeset/base/281916
[2] http://lists.freebsd.org/pipermail/svn-src-head/2015-April/071019.html
r211608 | rpaulo | 2010-08-22 03:53:32 -0700 (Sun, 22 Aug 2010) | 8 lines
Kernel DTrace support for:
o uregs (sson@)
o ustack (sson@)
o /dev/dtrace/helper device (needed for USDT probes)
The work done by me was:
Sponsored by: The FreeBSD Foundation
plus a few netbsd-specific tweaks from me.
fixes PR 50790.
riastradh