glibc/sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h

58 lines
1.6 KiB
C
Raw Normal View History

/* Processor capability information handling macros - aarch64 version.
Copyright (C) 2017-2019 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
#ifndef _DL_PROCINFO_H
#define _DL_PROCINFO_H 1
#include <sys/auxv.h>
#include <unistd.h>
#include <ldsodefs.h>
#include <sysdep.h>
/* We cannot provide a general printing function. */
#define _dl_procinfo(type, word) -1
/* No additional library search paths. */
aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT This enables searching shared libraries in atomics/ when the hardware supports LSE atomics of armv8.1 so one can provide optimized variants of libraries in a portable way. LSE atomics does not affect library abi, the new instructions can interoperate with old ones. I considered the earlier comments on the patch https://sourceware.org/ml/libc-alpha/2018-04/msg00400.html https://sourceware.org/ml/libc-alpha/2018-04/msg00625.html It turns out that the way glibc dynamic linker decides on the search path is not very flexible: it wants to use hwcap bits and associated strings. So some targets reuse hwcap bits for glibc internal purposes to affect the search logic. But hwcap is an interface with the kernel, glibc should not allocate bits in it for its internal logic as that limits future hwcap extensions and confusing to users who expect to see hwcap bits in ifunc resolvers. Instead of rewriting the dynamic linker path logic (which affects all targets) this patch just uses the existing mechanism, however this means that the path name has to be the hwcap name "atomics" and cannot be changed to something more meaningful to users. It is hard to tell how much performance benefit this can give, in principle armv8.1 atomics can be better optimized in the hardware, so it can make a difference for synchronization heavy code. On some systems such multilib setup may be the only viable way to get optimized libraries used. * sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT): Add HWCAP_ATOMICS.
2018-06-28 14:30:32 +00:00
#define HWCAP_IMPORTANT HWCAP_ATOMICS
static inline const char *
__attribute__ ((unused))
_dl_hwcap_string (int idx)
{
return (unsigned)idx < _DL_HWCAP_COUNT ? GLRO(dl_aarch64_cap_flags)[idx] : "";
};
static inline int
__attribute__ ((unused))
_dl_string_hwcap (const char *str)
{
for (int i = 0; i < _DL_HWCAP_COUNT; i++)
{
if (strcmp (str, _dl_hwcap_string (i)) == 0)
return i;
}
return -1;
};
/* There're no platforms to filter out. */
#define _DL_HWCAP_PLATFORM 0
#define _dl_string_platform(str) (-1)
#endif /* dl-procinfo.h */