Summary of changes:
- Use BAD_TYPECHECK to perform type checking in a cleaner way.
BAD_TYPECHECK is moved into sysdeps/mach/rpc.h to avoid duplication.
- Remove assertions for mach_msg_type_t since those won't work for
x86_64.
- Update message structs to use mach_msg_type_t directly.
- Use designated initializers.
Message-Id: <ZFa+roan3ioo0ONM@jupiter.tail36e24.ts.net>
Reduce the usage of alloca() to the bare minimum to avoid the potential
for stack overflow. Use __strndup to simplify the code.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Summary of the changes:
- Introduce BAD_TYPECHECK from MiG to make it simpler to do type
checking.
- Replace int type with mach_msg_type_t. This assumes that
mach_msg_type_t is always the same size as int which is not true for
x86_64.
- Calculate the size and align using PTR_ALIGN_UP, which is a bit
cleaner and similar to what we do elsewhere.
- Define mach_msg_type_t to check using designated initializers.
Message-Id: <ZFMvrIkvoCSxqB/C@jupiter.tail36e24.ts.net>
Summary of the changes:
- Update msg_align to use ALIGN_UP like we have done in previous
patches. Use it below whenever necessary to avoid repeating the same
alignment logic.
- Define BAD_TYPECHECK to make it easier to do type checking in a few
places below.
- Update io2mach_type to use designated initializers.
- Make RetCodeType use mach_msg_type_t. mach_msg_type_t is 8 byte for
x86_64, so this make it portable.
- Also call msg_align for _IOT_COUNT2/_IOT_TYPE2 since it is more
correct.
Message-Id: <ZFMvVsuFKwIy2dUS@jupiter.tail36e24.ts.net>
arm_sve.h depends on stdint.h but that relies on libc headers unless
compiled in freestanding mode. Without this change a bootstrap glibc
build (that uses a compiler without installed libc headers) failed with
checking for availability of SVE ACLE... In file included from [...]/arm_sve.h:28,
from conftest.c:1:
[...]/stdint.h:9:16: fatal error: stdint.h: No such file or directory
9 | # include_next <stdint.h>
| ^~~~~~~~~~
compilation terminated.
configure: error: mathvec is enabled but compiler does not have SVE ACLE. [...]
This patch enables libmvec on AArch64. The proposed change is mainly
implementing build infrastructure to add the new routines to ABI,
tests and benchmarks. I have demonstrated how this all fits together
by adding implementations for vector cos, in both single and double
precision, targeting both Advanced SIMD and SVE.
The implementations of the routines themselves are just loops over the
scalar routine from libm for now, as we are more concerned with
getting the plumbing right at this point. We plan to contribute vector
routines from the Arm Optimized Routines repo that are compliant with
requirements described in the libmvec wiki.
Building libmvec requires minimum GCC 10 for SVE ACLE. To avoid raising
the minimum GCC by such a big jump, we allow users to disable libmvec
if their compiler is too old.
Note that at this point users have to manually call the vector math
functions. This seems to be acceptable to some downstream users.
Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
dev_t are 64bit on Linux ports, so better increase their size on 64bit
Hurd. It happens that this helps with BZ 23084 there: st_dev has type fsid_t
(quad) and is specified by POSIX to have type dev_t. Making dev_t 64bit
makes these match.
This patch updates build-many-glibcs.py to use Linux 6.3 and GCC 13
branch by default.
Tested with build-many-glibcs.py (host-libraries, compilers and glibc
builds).
GCC docs explicitly list perror () as a good candidate for using
__attribute__ ((cold)). So apply __COLD to perror () and similar
functions.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Message-Id: <20230429131223.2507236-3-bugaevc@gmail.com>
include/regex.h had not been updated during the int -> Idx transition,
and the prototypes don't matched the definitions in regexec.c.
In regcomp.c, most interfaces were updated for Idx, except for two ones
guarded by #if _LIBC.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The standards want msg_lspid/msg_lrpid/shm_cpid/shm_lpid to be pid_t, see BZ
23083 and 23085.
We can leave them __rpc_pid_t on i386 for ABI compatibility, but avoid
hitting the issue on 64bit.
The standards want uid/cuid to be uid_t, gid/cgid to be gid_t and mode to be
mode_t, see BZ 23082.
We can leave them short ints on i386 for ABI compatibility, but avoid
hitting the issue on 64bit.
bits/ipc.h ends up being exactly the same in sysdeps/gnu/ and
sysdeps/unix/sysv/linux/, so remove the latter.
The standards want l_type and l_whence to be short ints, see BZ 23081.
We can leave them ints on i386 for ABI compatibility, but avoid hitting the
issue on 64bit.
cmsg_len is supposed to be socklen_t according to standards, but it was made
size_t on Linux, see BZ 16919. For ports that have it socklen_t, SIZE_MAX is
too large. We can however explicitly cast it to the type of cmsg_len so it
will fit according to that type.
These were created by creating stub files, running 'make update-abi',
and reviewing the results.
Also, set baseline ABI to GLIBC_2.38, the (upcoming) first glibc
release to first have x86_64-gnu support.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
If we're trying to interrupt an interruptible RPC, but the server fails
to respond to our __interrupt_operation () call, we instead destroy the
reply port we were expecting the reply to the RPC on.
Instead of deallocating the name completely, replace it with a dead
name, so the name won't get reused for some other right, and deallocate
it in _hurd_intr_rpc_mach_msg once we return from the signal handler.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Message-Id: <20230429201822.2605207-4-bugaevc@gmail.com>
We make lib{mach,hurd}user.so only call __mig_strlen which can be
relocated before libc.so is relocated, similar to what is done with
__mig_memcpy.
Message-Id: <ZE8DTRDpY2hpPZlJ@jupiter.tail36e24.ts.net>
Normally, in static builds, the first code that runs is _start, in e.g.
sysdeps/x86_64/start.S, which quickly calls __libc_start_main, passing
it the argv etc. Among the first things __libc_start_main does is
initializing the tunables (based on env), then CPU features, and then
calls _dl_relocate_static_pie (). Specifically, this runs ifunc
resolvers to pick, based on the CPU features discovered earlier, the
most suitable implementation of "string" functions such as memcpy.
Before that point, calling memcpy (or other ifunc-resolved functions)
will not work.
In the Hurd port, things are more complex. In order to get argv/env for
our process, glibc normally needs to do an RPC to the exec server,
unless our args/env are already located on the stack (which is what
happens to bootstrap processes spawned by GNU Mach). Fetching our
argv/env from the exec server has to be done before the call to
__libc_start_main, since we need to know what our argv/env are to pass
them to __libc_start_main.
On the other hand, the implementation of the RPC (and other initial
setup needed on the Hurd before __libc_start_main can be run) is not
very trivial. In particular, it may (and on x86_64, will) use memcpy.
But as described above, calling memcpy before __libc_start_main can not
work, since the GOT entry for it is not yet initialized at that point.
Work around this by pre-filling the GOT entry with the baseline version
of memcpy, __memcpy_sse2_unaligned. This makes it possible for early
calls to memcpy to just work. The initial value of the GOT entry is
unused on x86_64, and changing it won't interfere with the relocation
being performed later: once _dl_relocate_static_pie () is called, the
baseline version will get replaced with the most suitable one, and that
is what subsequent calls of memcpy are going to call.
Checked on x86_64-gnu.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Message-Id: <20230429201822.2605207-6-bugaevc@gmail.com>
Checked on x86_64-gnu.
[samuel.thibault@ens-lyon.org: Restored same comments as on i386]
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Message-Id: <20230429201822.2605207-3-bugaevc@gmail.com>
We need to align on uintptr_t to make this work for x86_64,
otherwise things will go wrong when RPCs return errors.
Message-Id: <ZE3aPH7uCEDti47H@jupiter.tail36e24.ts.net>
This should hopefully hint the compiler that they are unlikely
to be called.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Message-Id: <20230429131223.2507236-2-bugaevc@gmail.com>
This expands to __attribute__ ((cold)) when supported. It should be
used to mark up functions that are invoked rarely.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
We need to set file_name, not update retryname. This is what the other
branches do.
Before this change, any attempt to access such a file would segfault due
to file_name being unset:
$ settrans -ac /tmp/my-machtype /hurd/magic machtype
$ cat /tmp/my-machtype
Segmentation fault
Checked on i686-gnu.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Message-Id: <20230429131354.2507443-7-bugaevc@gmail.com>
If the process has set the close-on-exec flag for the file descriptor,
it expects the file descriptor to get closed on exec, even if we replace
what the file descriptor refers to.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Message-Id: <20230429131354.2507443-6-bugaevc@gmail.com>
If any of the early boot-up tasks calls exit () or returns from main (),
terminate it properly instead of crashing on trying to dereference
_hurd_ports and getting forcibly terminated by the kernel.
We sadly cannot make the __USEPORT macro do the check for _hurd_ports
being unset, because it evaluates to the value of the expression
provided as the second argument, and that can be of any type; so there
is no single suitable fallback value for the macro to evaluate to in
case _hurd_ports is unset. Instead, each use site that wants to care for
this case will have to do its own checking.
Checked on x86_64-gnu.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Message-Id: <20230429131354.2507443-4-bugaevc@gmail.com>
Each libc_hidden_def should be placed immediately next to its function,
not in some random unrelated place.
No functional change.
Fixes: 653d74f12a
"hurd: Global signal disposition"
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Message-Id: <20230429131354.2507443-2-bugaevc@gmail.com>
This block of code was doing exactly what _hurd_self_sigstate does; so
just call that and let it do its job.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Message-Id: <20230429131354.2507443-1-bugaevc@gmail.com>
There are reports for hang in __check_pf:
https://github.com/JoeDog/siege/issues/4
It is reproducible only under specific configurations:
1. Large number of cores (>= 64) and large number of threads (> 3X of
the number of cores) with long lived socket connection.
2. Low power (frequency) mode.
3. Power management is enabled.
While holding lock, __check_pf calls make_request which calls __sendto
and __recvmsg. Since __sendto and __recvmsg are cancellation points,
lock held by __check_pf won't be released and can cause deadlock when
thread cancellation happens in __sendto or __recvmsg. Add a cancellation
cleanup handler for __check_pf to unlock the lock when cancelled by
another thread. This fixes BZ #20975 and the siege hang issue.
__GLIBC_FLT_EVAL_METHOD will effect the definition of float_t and
double_t, currently we'll set __GLIBC_FLT_EVAL_METHOD to 2 when
__FLT_EVAL_METHOD__ is -1, that means we'll define float_t and double_t
to long double.
However some target isn't natively (HW) support long double like AArch64 and
RISC-V, they defined long double as 128-bits IEEE 754 floating point type.
That means setting __GLIBC_FLT_EVAL_METHOD to 2 will cause very inefficient
code gen for those target who didn't provide native support for long
double, and that's violate the spirit float_t and double_t - most efficient
types at least as wide as float and double.
So this patch propose to remap __GLIBC_FLT_EVAL_METHOD to 0 rather than
2 when __FLT_EVAL_METHOD__ is -1, which means we'll use float/double
rather than long double for float_t and double_t.
Note: __FLT_EVAL_METHOD__ == -1 means the precision is indeterminable,
which means compiler might using indeterminable precision during
optimization/code gen, clang will set this value to -1 when fast
math is enabled.
Note: Default definition float_t and double_t in current glibc:
| __GLIBC_FLT_EVAL_METHOD | float_t | double_t
| 0 or 16 | float | double
| 1 | double | doulbe
| 2 | long double | long double
More complete list see math/math.h
Note: RISC-V has defined ISA extension to support 128-bits IEEE 754
floating point operations, but only rare RISC-V core will implement that.
Related link:
[1] LLVM issue (__FLT_EVAL_METHOD__ is set to -1 with Ofast. #60781):
https://github.com/llvm/llvm-project/issues/60781
[2] Last version of this patch: https://sourceware.org/pipermail/libc-alpha/2023-February/145622.html
Acked-by: Palmer Dabbelt <palmer@rivosinc.com> # RISC-V
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Link: https://inbox.sourceware.org/libc-alpha/20230314151948.12892-1-kito.cheng@sifive.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
