Also use __func__ rather than hardcoding the function name. This code
now fits in 80 columns without splitting the log message.
Reviewed by: zlei
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39619
The closing parenthesis was in the wrong location, so instead of assigning the return value to krbret and then comparing it to zero, we were assigning the result of the comparison to krbret and then comparing that to zero. This has no practical significance since the value is not used after the loop terminates.
PR: 229719
Reviewed by: cy
Differential Revision: https://reviews.freebsd.org/D41299
Unzip from FreeBSD has been ported to libarchive.
Change usr.bin/unzip to use bsdunzip from libarchive.
Differential Revision: https://reviews.freebsd.org/D41239
PR: 272845 (exp-run)
MFC after: 1 month
This performs very well. x86-64-v3 and x86-64-v4 kernels were written,
too, but performed worse than the baseline kernel on short strings.
These may be added at a future point in time if the performance issues
can be fixed.
os: FreeBSD
arch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
│ strlen_scalar.out │ strlen_baseline.out │
│ B/s │ B/s vs base │
Short 1.667Gi ± 1% 2.676Gi ± 1% +60.55% (p=0.000 n=20)
Mid 5.459Gi ± 1% 8.756Gi ± 1% +60.39% (p=0.000 n=20)
Long 15.34Gi ± 0% 52.27Gi ± 0% +240.64% (p=0.000 n=20)
geomean 5.188Gi 10.70Gi +106.24%
Sponsored by: The FreeBSD Foundation
Approved by: kib
Reviewed by: mjg jrtc27
Differential Revision: https://reviews.freebsd.org/D40693
Add a framework for selecting from one of multiple implementations
of a function based on amd64 architecture level (cf. amd64 SysV
ABI supplement).
Sponsored by: The FreeBSD Foundation
Approved by: kib
Reviewed by: jrtc27
Differential Revision: https://reviews.freebsd.org/D40693
This removes the __ieee754_ prefix from a number of the math functions.
msun/src/math_private.h contains the statement that
/*
* ieee style elementary functions
*
* We rename functions here to improve other sources' diffability
* against fdlibm.
*/
#define __ieee754_sqrt sqrt
...
Here, fdlibm refers to https://netlib.org/fdlibm. It is seen from
https://netlib.org/fdlibm/readme that this prefix was used to
differentiate between different standards:
Wrapper functions will twist the result of the ieee754
function to comply to the standard specified by the value
of _LIB_VERSION
if _LIB_VERSION = _IEEE_, return the ieee754 result;
if _LIB_VERSION = _SVID_, return SVID result;
if _LIB_VERSION = _XOPEN_, return XOPEN result;
if _LIB_VERSION = _POSIX_, return POSIX/ANSI result.
(These are macros, see fdlibm.h for their definition.)
AFAICT, FreeBSD has never supported these wrappers. In addition, as C99,
principally the long double, functions were added to libm, this
convention was not maintained. Given that only 148 of 324 files under
lib/msun contain a "Copyright (C) 1993 by Sun Microsystems" statement,
the removal of the __ieee754_ prefix provides consistency across all
source files.
The last time someone compared lib/msun to fdlibm appears to be
commit 3f70824172
Author: David Schultz <das@FreeBSD.org>
Date: Fri Feb 4 18:26:06 2005 +0000
Reduce diffs against vendor source (Sun fdlibm 5.3).
The most recent fdlibm RCS string that appears in a Sun Microsystem
copyrighted file is date "95/01/18". With Oracle Corporation's
acquisition of Sun Microsystems in 2009, it is unlikely that fdlibm will
ever be updated. A search for fdlibm at https://opensource.oracle.com/
yields no hits.
Finally, OpenBSD removed the use of this prefix over 21 years ago. pSee
revision 1.6 of OpenBSD's math_private.h.
Note: this does not drop the __ieee754_ prefix from the trigonometric
argument reduction functions, e.g., __ieee754_rem_pio2. These functions
are internal to the libm and exported through Symbol.map; and thus,
reserved for the implementation.
PR: 272783
MFC after: 1 week
patch to fix half-cycle trigonometric functions
Paul Zimmermann, a MPFR developer, contacted me about large errors in
the half-cycle trigonometric functions. I've have investigated these
issues and developed the attached patch. The float, double, and ld80
(long double) changes have been tested.
Caveat emptor: The ld128 changes have not been compiled. The ld128
changes have not been tested. I do not have access to a system that
uses ld128 floating point.
Here is an itemized list of changes:
* lib/msun/src/math_private.h:
. Add fast floor macros to compute the integer part of |x| for
0 <= |x| 01xp(N-1), where N is the precision of the type of x.
These macros are used in the half-cycle trigonometric functions
(e.g., sinpi(x)).
. The FFLOOR80 macros is used with the Intel 80-bit extended double
functions. This macors corrects an off-by-one error, which led to
enormous error for |x| > 0x1p32.
* lib/msun/src/s_cospif.c:
* lib/msun/src/s_cospi.c:
* lib/msun/ld80/s_cospil.c:
. Update Copyright years.
. Use FFLOOR*() macro to get integer part of |x|.
. Correct handle the range 0x1p(N-1) <= |x| < 0x1pN. Here, one needs
to determine if the integral value of |x| is even or odd to choose
+1 or -1. If |x| >= 0x1pN, always return +1.
* lib/msun/src/s_sinpif.c:
* lib/msun/src/s_sinpi.c:
* lib/msun/ld80/s_sinpil.c:
. Update Copyright years.
. Use FFLOOR*() macro to get integer part of |x|.
* lib/msun/src/s_tanpif.c:
* lib/msun/src/s_tanpi.c:
* lib/msun/ld80/s_tanpil.c:
. Update Copyright years.
. For +-0.5, return +-inf. Previously, tanpi[fl]() returned an NaN.
. Use FFLOOR*() to get integer part of |x|. Need to determine if the
integer part is even or odd. This is used to set +-0 for |x|
integral
and +-inf for (n+1/2).
. For 0x1p(N-1) <= |x| < 0x1pN need to determine if x is an even or
odd
integer to select +0 or -0. For |x| >= 0x1pN, it is always an even
integer, select 0.
. Note, tanpi[fl](x) is an odd function, so one needs to consider
tanpi[fl](-|x|) = - tanpi[fl](|x|).
* lib/msun/ld128/s_cospil.c:
* lib/msun/ld128/s_sinpil.c:
* lib/msun/ld128/s_tanpil.c:
. Update Copyright years.
. These routines use an FFLOOR128 macros, which likely should be
replaced by a bit twiddling algorithm.
. The same considerations above are applied to 0x1p112 <= |x| <
0x1p113,
and |x| >= 0x1p113 cases.
. Note, even and odd determination used fmodl(x,2.), which is likely
slow.
PR: 272742
MFC after: 1 week
David Das (das@) committed Bruce Evan's (bde's) WIP code for
expl() and logl() in git revision 25a4d6bfda. That code
included instrumentation that allowed bde to generate pari
scripts used in testing/debugging. This patch removes that
instrumentation as it is unlikely that others will ever use it.
* math/libm/msun/src/math_private.h:
. Remove bde's macros for the generation of pari scripts.
* math/libm/msun/ld128/s_expl.c:
* math/libm/msun/ld128/s_logl.c:
* math/libm/msun/ld80/s_expl.c:
* math/libm/msun/ld80/s_logl.c:
. Remove bde's DOPRINT_START macro.
. Change RETURNP to RETURNF.
. Change RETURN2P to RETURNF. Adjust arguments as needed.
. Change RETURNPI to RETURNI.
. Change RETURN2PI to RETURNI. Adjust arguments as needed.
PR: 272765
MFC after: 1 week
libproc's PR_REQUESTED is not implemented on FreeBSD. Remove dead code
in dtrace that would handle it.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D41225
When MFC'ing commit dad11f990e to stable/12, the child would dump core
when dtrace exited. It was getting SIGTRAP, even though proc_detach
sent a SIGKILL. I could not find the reason for this difference in
behavior from main (and stable/13). The present change, however, works
as expected, probably due the proc_wkilled special case in kern_ptrace.
It also seems like a more obvious approach.
While I'm here, fix two other issues in the previous code:
It would SIGKILL a tracee even in read-only mode.
It would SIGSTOP/SIGCONT the tracee if ptrace succeeded but errno happened
to be EBUSY for some other reason.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D41122
Machine endianness is not very important in understanding the inet*
functions; the endianness of the VAX is especially so.
PR: 272728
Sponsored by: The FreeBSD Foundation
The removal of the sparc64 support in February 2020 obsoleted the
VTOC8 partitioning scheme as no other FreeBSD platform makes use
of it. Moreover, the code is bitrotting as nothing defines e. g.
LOADER_VTOC8_SUPPORT any more and, thus, should go now, too. With
this change, the following commits are reverted as far as VTOC8
is concerned and parts haven't already previously been deleted
along with prior sparc64 removals:
094fcb157da7d366e958ba8d50d08b
The alignment example d9711c28ef
added to the VTOC8 section of gpart.8 is folded into the MBR one.
This should finally conclude the deorbit of sparc64-specific bits.
We had joy, we had fun
we ran Unix on a Sun.
But that source and the song
of FreeBSD have all gone.
Credits to Michael Bueker for the original "Unix on a Sun" and Rod
McKuen for the "Seasons in the Sun" lyrics.
Ensure that we allocate enough memory for the packed nvlist, no matter
what size hint was provided.
MFC after: 1 week
Reported by: R. Christian McDonald <rcm@rcm.sh>
Sponsored by: Rubicon Communications, LLC ("Netgate")
Enable LIB32 option on aarch64, defaulting to YES; it had defaulted
to "broken". Add required variables for how to compile lib32 on
arm. Use /usr/include/arm for armv7 (32-bit) headers, analogous to
/usr/include/i386 on amd64. Omit libomp from lib32; it is not
supported on armv7.
Reviewed by: jrtc27
Differential Revision: https://reviews.freebsd.org/D40945
In order to compile lib32 libraries and other 32-bit code on arm64,
<machine/foo.h> needs to be redirected to an arm header rather
than arm64 when building with -m32. Ifdef the arm64 headers that
are installed in /usr/include/machine and used by user-level software
(including references from /usr/include/*.h) so that if __arm__ is
defined when including the arm64 version, <arm/foo.h> is included
rather than using the rest of the file's contents. Some arm headers
had no arm64 equivalent; headers were added just to do the redirection.
These files use #error if __arm__ is not defined to guard against
confusion. Also add an include/arm Makefile, and modify Makefiles
as needed to install everything, including the arm files in
/usr/include/arm. fenv.h comes from lib/msun/arm/fenv.h.
The new arm64 headers are:
acle-compat.h
cpuinfo.h
sysreg.h
Reviewed by: jrtc27, imp
Differential Revision: https://reviews.freebsd.org/D40944
The FreeBSD driver support for clang tested explicitly for 32-bit
Intel, MIPS, or PowerPC targets where /usr/lib32/libcrt1.o was
present to decide whether -m32 should use /usr/lib32. At jrtc27's
suggestion, simply test for a 32-bit platform rather than adding
arm to the list. Upstreamed as
3450272fc2
Bump the freebsd version to force a bootstrap build. This is one
step in adding support for -m32 on arm64.
Reviewed by: jrtc27, brooks, dim
Differential Revision: https://reviews.freebsd.org/D40943
There is no need for this to be versioned after the removal of armv4/v5
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41139
Libarchive 3.7.0
Important changes (relevant to FreeBSD):
#1814 Do not account for NULL terminator when comparing with "TRAILER!!!"
#1818 Add ability to produce multi-frame zstd archives
#1840 year 2038 fix for pax archives on platforms with 64-bit time_t
#1860 Make single bit bitfields unsigned to avoid clang 16 warning
#1869 Fix FreeBSD builds with WARNS=6
#1873 bsdunzip ported to libarchive from FreeBSD
#1894 read support for zstd compression in 7zip archives
#1918 ARM64 filter support in 7zip archives
MFC after: 2 weeks
PR: 272567 (exp-run)
Extrapolate from the context what the intention for the rest of the
comment probably was -- that the C/POSIX (and now C.UTF-8) locales may
avoid an allocation and reuse a global table.
Reviewed by: bapt
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D41087
This ensures GNU as generates a R_X86_64_PLT32 relocation instead of
R_X86_64_32.
Reviewed by: kib
Fixes: c969310c99 csu: Implement _start using as to satisfy unwinders on x86_64
Differential Revision: https://reviews.freebsd.org/D41101
beadm will recursively promote deep BE datasets. In order to match the
beadm behavior, we need to recursively iterate over child filesystems
and promote them along the way.
This patch further refines the work from D40903, completing the fix for
promotion.
Reviewed by: kevans, rew
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D40972
The current versions of lib/msun/src/s_cospi.c, s_sinpi.c and s_tanpi.c
all exhibit the same defect. After checking for various numeric ranges,
they check to see whether the input argument is a NaN or an Infinity.
However, the code uses a value of 0x7f80000 instead of the correct value
of 0x7ff00000.
If you review s_cospif.c, s_sinpif.c, and s_tanpif.c, you will see that
the equivalent statements in these functions are accurate and have
appropriate source comments.
The impact of these defects is to flag some valid input values as
invalid and raise a pole error (divide by zero).
Reported by: Paul Green <Paul.Green@stratus.com>
PR: 272539
MFC after: 1 week
bcmp() returned the number of remaining bytes when the main loop exits.
In case of a match, this is zero, else a positive integer. On systems
where SIZE_MAX > INT_MAX, the implicit conversion from size_t to int in
the return value may cause the number of remaining bytes to overflow,
becoming zero and falsely indicating a successful comparison.
Fix the bug by always returning 0 on equality, 1 otherwise.
PR: 272474
Approved by: emaste
Reviewed by: imp
MFC After: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41011
Gcc warns of infinite recursion if we use __builtin_ffs*() to
implement ffs*(). This is because gcc uses ffs() to implement
these on some platforms. Sidestep the warning by using
__builtin_ctz*() for these.
Sponsored by: FreeBSD Foundation
Reported by: jlduran@gmail.com, jhb
Fixes: ee8b0c43 (D40730)
Reviewed by: jhb, mhorne
Approved by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D40966
We include paths.h in getlocalbase.c, which defines _PATH_LOCALBASE.
This will override a definition on the command line, meaning it is
impossible to override like how the manpage says you can, and it means
the code to provide a fallback default is dead as the macro is always
defined.
Instead, introduce a new LOCALBASE_PATH macro like LOCALBASE_CTL_LEN
that can be set on the command line and will default to the system's
existing _PATH_LOCALBASE to avoid duplicating the default here.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D40975
The right unwinding stop indicator should be CFI-undefined PC.
https://dwarfstd.org/doc/Dwarf3.pdf - page 118:
If a Return Address register is defined in the virtual unwind table,
and its rule is undefined (for example, by DW_CFA_undefined), then
there is no return address and no call address, and the virtual
unwind of stack activations is complete.
The hack localizing _start1 symbol removed.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D40624
Normally, modern unwinders uses Dwarf information to unwind stack,
however in case when the code is not annotated by Dwarf instructions,
unwinders fallbacks to a frame-pointer based algorithm.
That is allows libunwind to unwind stack from global constructors and
destructors. Also it makes gdb happy as it printed nonexistent frame
before.
Reviewed by: kib, imp
Differential Revision: https://reviews.freebsd.org/D40948
This matches the beadm behavior; generally, we need to keep promoting
until the BE is no longer a clone from a snapshot. This fixes scenarios
where the dataset associated with a BE's origin is itself a clone,
activating the BE previously would promote it to a clone of the origin's
origin.
We could keep using be_get_dataset_props here, except for two
annoyances:
1.) I couldn't find a clean way to just clear an nvlist rather than
having to re-alloc it, and I didn't want to just remove the one prop
we're inspecting out of it.
2.) That's a lot of overhead when all we want to do is fetch the origin
anyways.
Note that this is not a complete fix, but it does fix the majority of
cases; deep BE subordinates are still notably broken, pending a patch
from Christian.
Reported by: R. Christian McDonald <rcm@rcm.sh>
Reviewed by: rew
Differential Revision: https://reviews.freebsd.org/D40903
In the process, delete a COMPAT_SOFTFP remnant that was missed in
previous sweeps.
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: emaste, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40931
The use isn't any more generic, just the variable itself, which will
allow COMPAT_32BIT to be removed. The fact we even have to check
COMPAT_LIBCOMPAT here in order to pass the right flags to CPP points at
our libcompat infrastructure not suitably modifying the CPP variable
(which we barely use for world; this and bsd.symver.mk are the two
uses, and the latter could benefit from the right flags too), but this
change doesn't attempt to fix that.
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: emaste, imp, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40930
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40929
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: imp, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40927
Having the symbols exported by libc differ between i386 and amd64 lib32
is questionable. Since these files build just fine today, stop guarding
them with !defined(COMPAT_32BIT). Whether or not they work at run time
is a different matter, but an i386 jail would be similarly affected if
not, so that's not a problem with lib32.
Reviewed by: kib, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40937
