mirror of
https://sourceware.org/git/glibc.git
synced 2024-12-28 05:21:13 +00:00
b34b46b880
C23 adds a header <stdbit.h> with various functions and type-generic macros for bit-manipulation of unsigned integers (plus macro defines related to endianness). Implement this header for glibc. The functions have both inline definitions in the header (referenced by macros defined in the header) and copies with external linkage in the library (which are implemented in terms of those macros to avoid duplication). They are documented in the glibc manual. Tests, as well as verifying results for various inputs (of both the macros and the out-of-line functions), verify the types of those results (which showed up a bug in an earlier version with the type-generic macro stdc_has_single_bit wrongly returning a promoted type), that the macros can be used at top level in a source file (so don't use ({})), that they evaluate their arguments exactly once, and that the macros for the type-specific functions have the expected implicit conversions to the relevant argument type. Jakub previously referred to -Wconversion warnings in type-generic macros, so I've included a test with -Wconversion (but the only warnings I saw and fixed from that test were actually in inline functions in the <stdbit.h> header - not anything coming from use of the type-generic macros themselves). This implementation of the type-generic macros does not handle unsigned __int128, or unsigned _BitInt types with a width other than that of a standard integer type (and C23 doesn't require the header to handle such types either). Support for those types, using the new type-generic built-in functions Jakub's added for GCC 14, can reasonably be added in a followup (along of course with associated tests). This implementation doesn't do anything special to handle C++, or have any tests of functionality in C++ beyond the existing tests that all headers can be compiled in C++ code; it's not clear exactly what form this header should take in C++, but probably not one using macros. DIS ballot comment AT-107 asks for the word "count" to be added to the names of the stdc_leading_zeros, stdc_leading_ones, stdc_trailing_zeros and stdc_trailing_ones functions and macros. I don't think it's likely to be accepted (accepting any technical comments would mean having an FDIS ballot), but if it is accepted at the WG14 meeting (22-26 January in Strasbourg, starting with DIS ballot comment handling) then there would still be time to update glibc for the renaming before the 2.39 release. The new functions and header are placed in the stdlib/ directory in glibc, rather than creating a new toplevel stdbit/ or putting them in string/ alongside ffs. Tested for x86_64 and x86. |
||
---|---|---|
.. | ||
examples | ||
argp.texi | ||
arith.texi | ||
charset.texi | ||
check-safety.sh | ||
conf.texi | ||
contrib.texi | ||
creature.texi | ||
crypt.texi | ||
ctype.texi | ||
debug.texi | ||
dir | ||
dynlink.texi | ||
errno.texi | ||
fdl-1.3.texi | ||
filesys.texi | ||
freemanuals.texi | ||
getopt.texi | ||
header.texi | ||
install-plain.texi | ||
install.texi | ||
intro.texi | ||
io.texi | ||
ipc.texi | ||
job.texi | ||
lang.texi | ||
lgpl-2.1.texi | ||
libc-texinfo.sh | ||
libc.texinfo | ||
libcbook.texi | ||
llio.texi | ||
locale.texi | ||
macros.texi | ||
maint.texi | ||
Makefile | ||
math.texi | ||
memory.texi | ||
message.texi | ||
nss.texi | ||
nsswitch.texi | ||
pattern.texi | ||
pipe.texi | ||
platform.texi | ||
probes.texi | ||
process.texi | ||
README.pretty-printers | ||
README.tunables | ||
resource.texi | ||
search.texi | ||
setjmp.texi | ||
signal.texi | ||
socket.texi | ||
startup.texi | ||
stdbit.texi | ||
stdio-fp.c | ||
stdio.texi | ||
string.texi | ||
summary.pl | ||
sysinfo.texi | ||
syslog.texi | ||
terminal.texi | ||
texinfo.tex | ||
texis.awk | ||
threads.texi | ||
time.texi | ||
tsort.awk | ||
tunables.texi | ||
users.texi | ||
xtract-typefun.awk |
TUNABLE FRAMEWORK ================= Tunables is a feature in the GNU C Library that allows application authors and distribution maintainers to alter the runtime library behaviour to match their workload. The tunable framework allows modules within glibc to register variables that may be tweaked through an environment variable. It aims to enforce a strict namespace rule to bring consistency to naming of these tunable environment variables across the project. This document is a guide for glibc developers to add tunables to the framework. ADDING A NEW TUNABLE -------------------- The TOP_NAMESPACE macro is defined by default as 'glibc'. If distributions intend to add their own tunables, they should do so in a different top namespace by overriding the TOP_NAMESPACE macro for that tunable. Downstream implementations are discouraged from using the 'glibc' top namespace for tunables they don't already have consensus to push upstream. There are three steps to adding a tunable: 1. Add a tunable to the list and fully specify its properties: For each tunable you want to add, make an entry in elf/dl-tunables.list. The format of the file is as follows: TOP_NAMESPACE { NAMESPACE1 { TUNABLE1 { # tunable attributes, one per line } # A tunable with default attributes, i.e. string variable. TUNABLE2 TUNABLE3 { # its attributes } } NAMESPACE2 { ... } } The list of allowed attributes are: - type: Data type. Defaults to STRING. Allowed types are: INT_32, UINT_64, SIZE_T and STRING. Numeric types may be in octal or hexadecimal format too. - minval: Optional minimum acceptable value. For a string type this is the minimum length of the value. - maxval: Optional maximum acceptable value. For a string type this is the maximum length of the value. - default: Specify an optional default value for the tunable. - env_alias: An alias environment variable 2. Use TUNABLE_GET/TUNABLE_SET/TUNABLE_SET_WITH_BOUNDS to get and set tunables. 3. OPTIONAL: If tunables in a namespace are being used multiple times within a specific module, set the TUNABLE_NAMESPACE macro to reduce the amount of typing. GETTING AND SETTING TUNABLES ---------------------------- When the TUNABLE_NAMESPACE macro is defined, one may get tunables in that module using the TUNABLE_GET macro as follows: val = TUNABLE_GET (check, int32_t, TUNABLE_CALLBACK (check_callback)) where 'check' is the tunable name, 'int32_t' is the C type of the tunable and 'check_callback' is the function to call if the tunable got initialized to a non-default value. The macro returns the value as type 'int32_t'. The callback function should be defined as follows: void TUNABLE_CALLBACK (check_callback) (int32_t *valp) { ... } where it can expect the tunable value to be passed in VALP. Tunables in the module can be updated using: TUNABLE_SET (check, val) where 'check' is the tunable name and 'val' is a value of same type. To get and set tunables in a different namespace from that module, use the full form of the macros as follows: val = TUNABLE_GET_FULL (glibc, cpu, hwcap_mask, uint64_t, NULL) TUNABLE_SET_FULL (glibc, cpu, hwcap_mask, val) where 'glibc' is the top namespace, 'cpu' is the tunable namespace and the remaining arguments are the same as the short form macros. The minimum and maximum values can updated together with the tunable value using: TUNABLE_SET_WITH_BOUNDS (check, val, min, max) where 'check' is the tunable name, 'val' is a value of same type, 'min' and 'max' are the minimum and maximum values of the tunable. To set the minimum and maximum values of tunables in a different namespace from that module, use the full form of the macros as follows: val = TUNABLE_GET_FULL (glibc, cpu, hwcap_mask, uint64_t, NULL) TUNABLE_SET_WITH_BOUNDS_FULL (glibc, cpu, hwcap_mask, val, min, max) where 'glibc' is the top namespace, 'cpu' is the tunable namespace and the remaining arguments are the same as the short form macros. When TUNABLE_NAMESPACE is not defined in a module, TUNABLE_GET is equivalent to TUNABLE_GET_FULL, so you will need to provide full namespace information for both macros. Likewise for TUNABLE_SET, TUNABLE_SET_FULL, TUNABLE_SET_WITH_BOUNDS and TUNABLE_SET_WITH_BOUNDS_FULL. ** IMPORTANT NOTE ** The tunable list is set as read-only after the dynamic linker relocates itself, so setting tunable values must be limited only to tunables within the dynamic linker, that too before relocation. FUTURE WORK ----------- The framework currently only allows a one-time initialization of variables through environment variables and in some cases, modification of variables via an API call. A future goals for this project include: - Setting system-wide and user-wide defaults for tunables through some mechanism like a configuration file. - Allow tweaking of some tunables at runtime