Last commit made on 2020-12-18
Get this branch:
git clone -b rearnsha/mte-v4.0

Branch merges

Branch information


Recent commits

9437fbd... by Richard Earnshaw <email address hidden> on 2020-12-18

aarch64: Add aarch64-specific files for memory tagging support

This final patch provides the architecture-specific implementation of
the memory-tagging support hooks for aarch64.

d3b950c... by Richard Earnshaw <email address hidden> on 2020-12-18

aarch64: Add sysv specific enabling code for memory tagging

Add various defines and stubs for enabling MTE on AArch64 sysv-like
systems such as Linux. The HWCAP feature bit is copied over in the
same way as other feature bits. Similarly we add a new wrapper header
for mman.h to define the PROT_MTE flag that can be used with mmap and
related functions.

We add a new field to struct cpu_features that can be used, for
example, to check whether or not certain ifunc'd routines should be
bound to MTE-safe versions.

Finally, if we detect that MTE should be enabled (ie via the glibc
tunable); we enable MTE during startup as required.

fd28928... by Richard Earnshaw <email address hidden> on 2020-12-18

linux: Add compatibility definitions to sys/prctl.h for MTE

Older versions of the Linux kernel headers obviously lack support for
memory tagging, but we still want to be able to build in support when
using those (obviously it can't be enabled on such systems).

The linux kernel extensions are made to the platform-independent
header (linux/prctl.h), so this patch takes a similar approach.

55d7ba9... by Richard Earnshaw <email address hidden> on 2020-12-18

malloc: Basic support for memory tagging in the malloc() family

This patch adds the basic support for memory tagging.

Various flavours are supported, particularly being able to turn on
tagged memory at run-time: this allows the same code to be used on
systems where memory tagging support is not present without neededing
a separate build of glibc. Also, depending on whether the kernel
supports it, the code will use mmap for the default arena if morecore
does not, or cannot support tagged memory (on AArch64 it is not

All the hooks use function pointers to allow this to work without
needing ifuncs.

3ee6ea7... by Richard Earnshaw <email address hidden> on 2020-12-18

elf: Add a tunable to control use of tagged memory

Add a new glibc tunable: mem.tagging. This is a decimal constant in
the range 0-255 but used as a bit-field.

Bit 0 enables use of tagged memory in the malloc family of functions.
Bit 1 enables precise faulting of tag failure on platforms where this
can be controlled.
Other bits are currently unused, but if set will cause memory tag
checking for the current process to be enabled in the kernel.

3b92559... by Richard Earnshaw on 2020-12-18

config: Allow memory tagging to be enabled when configuring glibc

This patch adds the configuration machinery to allow memory tagging to be
enabled from the command line via the configure option --enable-memory-tagging.

The current default is off, though in time we may change that once the API
is more stable.

69a7ca7... by Anssi Hannula <email address hidden> on 2020-01-27

ieee754: Remove unused __sin32 and __cos32

The __sin32 and __cos32 functions were only used in the now removed slow
path of asin and acos.

f67f9c9... by Anssi Hannula <email address hidden> on 2020-01-27

ieee754: Remove slow paths from asin and acos

asin and acos have slow paths for rounding the last bit that cause some
calls to be 500-1500x slower than average calls.

These slow paths are rare, a test of a trillion (
random inputs between -1 and 1 showed 32870 slow calls for acos and 4473
for asin, with most occurrences between -1.0 .. -0.9 and 0.9 .. 1.0.

The slow paths claim correct rounding and use __sin32() and __cos32()
(which compare two result candidates and return the closest one) as the
final step, with the second result candidate (res1) having a small offset
applied from res. This suggests that res and res1 are intended to be 1
ULP apart (which makes sense for rounding), barring bugs, allowing us to
pick either one and still remain within 1 ULP of the exact result.

Remove the slow paths as the accuracy is better than 1 ULP even without
them, which is enough for glibc.

Also remove code comments claiming correctly rounded results.

After slow path removal, checking the accuracy of 14.400.000.000 random
asin() and acos() inputs showed only three incorrectly rounded
(error > 0.5 ULP) results:
- asin(-0x1.ee2b43286db75p-1) (0.500002 ULP, same as before)
- asin(-0x1.f692ba202abcp-4) (0.500003 ULP, same as before)
- asin(-0x1.9915e876fc062p-1) (0.50000000001 ULP, previously exact)
The first two had the same error even before this commit, and they did
not use the slow path at all.

Checking 4934 known randomly found previously-slow-path asin inputs
shows 25 calls with incorrectly rounded results, with a maximum error of
0.500000002 ULP (for 0x1.fcd5742999ab8p-1). The previous slow-path code
rounded all these inputs correctly (error < 0.5 ULP).
The observed average speed increase was 130x.

Checking 36240 known randomly found previously-slow-path acos inputs
shows 42 calls with incorrectly rounded results, with a maximum error of
0.500000008 ULP (for 0x1.f63845056f35ep-1). The previous "exact"
slow-path code showed 34 calls with incorrectly rounded results, with the
same maximum error of 0.500000008 ULP (for 0x1.f63845056f35ep-1).
The observed average speed increase was 130x.

The functions could likely be trimmed more while keeping acceptable
accuracy, but this at least gets rid of the egregiously slow cases.

Tested on x86_64.

59d572e... by Lode Willems <email address hidden> on 2020-12-18

getenv: Move call to strlen to the branch it's used in.

The len variable is only used in the else branch.
We don't need the call to strlen if the name is 0 or 1 characters long.

2019-10-02 Lode Willems <email address hidden>

 * tdlib/getenv.c: Move the call to strlen into the branch it's used.

2ec40e6... by Joseph Myers <email address hidden> on 2020-12-17

Update kernel version to 5.10 in

This patch updates the kernel version in the test
to 5.10. (There are no new MAP_* constants covered by this test in
5.10 that need any other header changes.)

Tested with