`FPBits` is currently implemented as a general case and a specialization
for `long double` when `long double` is x86 80-bit extended precision.
This patch is a first of a series to provide an implementation based on
`FPType` instead of the C++ float type (which implementation is
architecture dependent).
Use a size smaller than the smallest supported page size so that we
don't
clobber over any guard pages, which may result in a segfault before
__stack_chk_fail can be called.
Also, move __stack_chk_fail outside of our namespace.
__stack_chk_fail should be provided by libc.a, not startup files.
Add __stack_chk_fail to existing linux and arm entrypoints. On Windows
(when
not targeting MinGW), it seems that the corresponding function
identifier is
__security_check_cookie, so no entrypoint is added for Windows.
Baremetal
targets also ought to be compileable with `-fstack-protector*`
There is no common header for this prototype, since calls to
__stack_chk_fail
are meant to be inserted by the compiler upon function return when
compiled
`-fstack-protector*`.
This one might be a bit controversial since the terminology has been
introduced from the start but I think `FRACTION_LEN` is a better name
here. AFAICT it really is "the number of bits after the decimal dot when
the number is in normal form."
`MANTISSA_WIDTH` is less precise as it's unclear whether we take the
leading bit into account.
This patch also renames most of the properties to use the `_LEN` suffix
and fixes useless casts or variables.
When building with compiler-rt enabled, warnings such as the following
are
observed:
llvm-project/llvm/build/projects/compiler-rt/../libc/include/llvm-libc-macros/linux/sys-stat-macros.h:46:9:
warning: 'S_IXOTH' macro redefined [-Wmacro-redefined]
#define S_IXOTH 00001
^
llvm-project/llvm/build/projects/compiler-rt/../libc/include/llvm-libc-macros/linux/fcntl-macros.h:61:9:
note: previous definition is here
#define S_IXOTH 01
^
It looks like we have these multiply defined. Deduplicate these flags;
users
should expect to find them in sys/stat.h. S_FIFO was wrong anyways
(should
have been S_IFIFO).
Also make type naming consistent by using `UIntType` instead of
`intU_t`.
This patch is a reland of #75196 but does not include the "use `FPBits`
instead of `FPBits_t`, `FPB`" part. This needs more work.
Reverts llvm/llvm-project#75196
GCC complains about change of meaning for `FPBits`
```
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/FPUtil/generic/FMod.h:188:9: error: declaration of ‘using FPBits = struct __llvm_libc_18_0_0_git::fputil::FPBits<T>’ changes meaning of ‘FPBits’ [-fpermissive]
188 | using FPBits = FPBits<T>;
| ^~~~~~
```
I'll reland with a different name.
This patch fixes cmake configuration when building with
LLVM_LIBC_INCLUDE_SCUDO. In libc, LIBC_TARGET_ARCHITECTURE is renamed
from `riscv64` to `riscv`. However, `compiler-rt`, hence `scudo`,
distinguishes `riscv32` and `riscv64` in the support list. As a result,
we need to translate the architecture name accordingly.
If a function is declared with stack-protector, the compiler may try to
load the TLS. However, inside certain runtime functions, TLS may not be
available. This patch disables stack protectors for such routines to fix
the problem.
Closes#74487.
This patch sinks `EXPLICIT_BIT_MASK` into `get_explicit_mantissa` - the
only function using it. Then it sinks the content of
`FPCommonProperties` directly into `FPProperties`.
An unsigned integer was being initialized with -1 to set all its bits to
1, but this doesn't work for the BigInt class which may be used as an
integer type on systems that don't support uint128 natively. This patch
moves the initialization to use ~T(0) instead.
This is a follow up on #74481 that migrates code from all
specializations into `FPCommonProperties` (except for
`EXPLICIT_BIT_MASK` in the `X86_Binary80` specialization)
According to [wikipedia](https://en.wikipedia.org/wiki/Exponent_bias)
the "biased exponent" is the encoded form that is always positive
whereas the unbiased form is the actual "real" exponent that can be
positive or negative.
`FPBits` seems to be using `unbiased_exponent` to describe the encoded
form (unsigned). This patch simply use `biased` instead of `unbiased`.
Fix#74258
This is a reland of #74837, the error went unnoticed because it compiles
fine on
clang-16 but not on clang-12 which is the version used on the buildbots.
The fix was to explicitly initialize `BigInt` variables in `constexpr`
operations: `BigInt<Bits, Signed> result(0);` instead of `BigInt<Bits,
Signed> result;`
Not that I'm very good at SFINAE, but it seems that conversion operators
are
perhaps difficult to compose with SFINAE. I saw an example that used one
layer
of indirection to have an explicit return type that could then be used
with
enable_if_t.
Link: https://stackoverflow.com/a/7604580Fixes: #74623
GCC warns:
```
libc/src/__support/wctype_utils.h:33:20: error: comparison of unsigned
expression in ‘< 0’ is always false [-Werror=type-limits]
33 | if (c > 127 || c < 0)
| ~~^~~
```
Looking into the signedness of wint_t, it looks like depending on the
platform,
__WINT_TYPE__ is defined to int or unsigned int depending on the
platform.
Link:
https://lab.llvm.org/buildbot/#/builders/250/builds/14891/steps/6/logs/stdio
Implement `prctl` as specified in
https://man7.org/linux/man-pages/man2/prctl.2.html.
This patch also includes test cases covering two simple use cases:
1. `PR_GET_NAME/PR_SET_NAME`: where userspace data is passed via arg2.
2. `PR_GET_THP_DISABLE`: where return value is passed via syscal retval.
Following up the discussion at
https://github.com/llvm/llvm-project/pull/73469#discussion_r1409593911
by @nickdesaulniers.
According to FreeBSD implementation
(https://android.googlesource.com/platform/bionic/+/refs/heads/main/libc/upstream-freebsd/lib/libc/stdlib/hcreate.c),
`hsearch` is able to handle the cases where the global table is not
properly initialized. To do this, FreeBSD actually allows hash table to
be dynamically resized. If the global table is uninitialized at the
first call, the table will be initialized with a minimal size; hence
subsequent insertion will be reasonable as the table grows
automatically.
This patch mimic such behaviors. More precisely, this patch introduces:
1. a full table iterator that scans each element in the table,
2. a resize routine that is automatically triggered whenever the load
factor is reached where it iterates the old table and insert the entries
into a new one,
3. more tests that cover the growth of the table.
