13 Commits

Author SHA1 Message Date
Schrodinger ZHU Yifan
03841e7ab8
[libc] add spin lock family functions (#100509)
This PR:
- add entrypoints for `pthread_spin_*`
- additionally, the fixes a typo that has been disabling lock related
tests
2024-08-06 21:02:54 -07:00
Eric977
44df89cc30
[libc] add pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock … (#100543) 2024-07-28 11:58:09 -07:00
Schrodinger ZHU Yifan
3db5c1eeb0
revert all tid changes (#100915) 2024-07-27 22:29:21 -07:00
Schrodinger ZHU Yifan
29be889c2c
reland "[libc] implement cached process/thread identity (#98989)" (#99765) 2024-07-20 10:25:40 -07:00
Schrodinger ZHU Yifan
415ca24f8e
Revert "[libc] implement cached process/thread identity" (#99559)
Reverts llvm/llvm-project#98989
2024-07-18 13:31:04 -07:00
Schrodinger ZHU Yifan
5c9fc3cdd7
[libc] implement cached process/thread identity (#98989)
migrated from https://github.com/llvm/llvm-project/pull/95965 due to
corrupted git history
2024-07-18 13:27:50 -07:00
Izaak Schroeder
b151c7e36a
[libc] Add dlfcn.h placeholder (#97501)
Adds `dlopen` and friends. This is needed as part of the effort to
compile `libunwind` + `libc` without baremetal mode. This is part of
https://github.com/llvm/llvm-project/issues/97191. This should still be
spec compliant, since `dlopen` always returns `NULL` and `dlerror`
always returns an error message.

> If dlopen() fails for any reason, it returns NULL.

> The function dlclose() returns 0 on success, and nonzero on error.

> Since the value of the symbol could actually be NULL (so that a NULL
return from dlsym() need not indicate an error), the correct way to test
for an error is to call dlerror() to clear any old error conditions,
then call dlsym(), and then call dlerror() again, saving its return
value into a variable, and check whether this saved value is not NULL.


See:
- https://linux.die.net/man/3/dlopen
2024-07-06 16:01:59 -07:00
OverMighty
b282259711
[libc][math][c23] Add {,u}fromfp{,x}{,f,l,f128} functions (#86003)
Fixes #85279.

cc @lntue
2024-03-25 10:26:22 -04:00
Joseph Huber
3dc1b5044e
[libc] Make 'printf' converter output "(null)" instead of "null" (#85845)
Summary:
Currently we print `null` for the null pointer in a `%s` expression.
Although it's not defined by the standard, other implementations choose
to use `(null)` to indicate this. We also currently print `(nullptr)` so
I think it's more consistent to use parens in both cases.
2024-03-19 14:44:59 -05:00
Schrodinger ZHU Yifan
f6f42af06f
[libc] Add shm_open/shm_unlink (#84974) 2024-03-18 11:40:07 -04:00
Michael Jones
9da9b5f867
[libc][docs] Document policy for non-standard func (#83212)
As encountered with <sys/queue.h>, we need a policy for how to handle
implementing functions that users need, but has no specific standard. In
that case, we should treat existing implementations as the standard and
try to match their behavior as best as possible.
2024-02-28 09:43:44 -08:00
Schrodinger ZHU Yifan
86e99e11e5
[libc] [search] improve hsearch robustness (#73896)
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.
2023-12-05 09:06:48 -08:00
Michael Jones
99686c5ed1 [libc][docs] Add undefined behavior doc to site
This document is based on the RFC posted to discourse:
https://discourse.llvm.org/t/rfc-defining-undefined-behavior-in-libc/

Reviewed By: sivachandra, lntue

Differential Revision: https://reviews.llvm.org/D152588
2023-06-12 11:13:51 -07:00