Add LIBC_ASSERT statements to FixedVector implementation, and zero out
the memory when the elements are removed to flag out-of-bound access and
dangling pointer/reference access.
This change unmasks the bug in one of FixedVector uses for atexit
handlers: dangling reference use, which was actually led to crashes in
the wild (with prod blockstore implementation). Fix it in this CL.
This reverts commit 93b83642ee.
- Correct riscv32 assumption about alignment (bit of a hack).
- Fix test case where the largest_small and smallest sizes are the
same.
- Fix assertion expressions.
- Fix incorrect small size in freestore_test.
- There may only be one small size for high alignment and small
pointers (riscv32).
- Don't rely on stack alignment in FreeList test.
This reworks the free store implementation in libc's malloc to use a
dlmalloc-style binary trie of circularly linked FIFO free lists. This
data structure can be maintained in logarithmic time, but it still
permits a relatively small implementation compared to other
logarithmic-time ordered maps.
The implementation doesn't do the various bitwise tricks or
optimizations used in actual dlmalloc; it instead optimizes for
(relative) readability and minimum code size. Specific optimization can
be added as necessary given future profiling.
Summary:
I'm going to attempt to move the `rpc.h` header to a separate folder
that we can install and include outside of `libc`. Before doing this I'm
going to try to trim up the file so there's not as many things I need to
copy to make it work. This dependency on `cpp::functional` is a low
hanging fruit. I only did it so that I could overload the argument of
the work function so that passing the id was optional in the lambda,
that's not a *huge* deal and it makes it more explicit I suppose.
Previously, the Quicksort implementation was written in the obvious way:
after each partitioning step, it explicitly recursed twice to sort the
two sublists. Now it compares the two sublists' sizes, and recurses only
to sort the smaller one. To handle the larger list it loops back round
to the top of the function, so as to handle it within the existing stack
frame.
This means that every recursive call is handling a list at most half
that of its caller. So the maximum recursive call depth is O(lg N).
Otherwise, in Quicksort's bad cases where each partition step peels off
a small constant number of array elements, the stack usage could grow
linearly with the array being sorted, i.e. it might be Θ(N).
I tested this code by manually constructing a List Of Doom that causes
this particular quicksort implementation to hit its worst case, and
confirming that it recursed very deeply in the old code and doesn't in
the new code. But I haven't added that list to the test suite, because
the List Of Doom has to be constructed in a way based on every detail of
the quicksort algorithm (pivot choice and partitioning strategy), so it
would silently stop being a useful regression test as soon as any detail
changed.
This patch adds the malloc.h header, declaring Scudo's mallopt
entrypoint when built LLVM_LIBC_INCLUDE_SCUDO, as well as two
constants that can be passed to it (M_PURGE and M_PURGE_ALL).
Due to limitations of the current build system, only the declaration
of mallopt is gated by LLVM_LIBC_INCLUDE_SCUDO, and the two new
constants are defined irrespectively of it. We may need to refine
this in the future.
Note that some allocators other than Scudo may offer a mallopt
implementation too (e.g. man 3 mallopt), albeit with different
supported input values. This patch only supports the specific case of
LLVM_LIBC_INCLUDE_SCUDO.
Summary:
This function can easily be implemented by forwarding it to the host
process. This shows up in a few places that we might want to test the
GPU so it should be provided. Also, I find the idea of the GPU
offloading work to the CPU via `system` very funny.
The call chain to `Mutex:lock` can be polluted by stack protector. For
completely safe, let's postpone the main TLS tearing down to a separate
phase.
fix#108030
Summary:
This provides the `_l` variants for the `stdlib.h` functions. These are
just copies of the same entrypoint and don't do anything with the locale
information.
Summary:
This patch implements 'getenv'. I was torn on how to implement this,
since realistically we only have access to this environment pointer in
the "loader" interface. An alternative would be to use an RPC call every
time, but I think that's overkill for what this will be used for. A
better solution is just to emit a common `DataEnvironment` that contains
all of the host visible resources to initialize. Right now this is the
`env_ptr`, `clock_freq`, and `rpc_client`.
I did this by making the `app.h` interface that Linux uses more general,
could possibly move that into a separate patch, but I figured it's
easier to see with the usage.
This is a non-feature change that enables most of the entrypoints for
aarch64 based runtime builds. It fixes an additional problem that some
compiler-rt targets are not defined at the time of dependency checking
thus leading to false-negatives.
Summary:
These functions are needed for `libc++` to link successfully. We can't
implement them well currently, so simply provide some stand-in
implementations. `realloc` will currently copy garbage and potentially
fault and `aligned_alloc` will work unless your alignment is more than
4K alignment. However, these should work in practice to get tests
running. I will write a real allocator soon™.
This requires the user to set the upper bounds of the heap by defining
the symbol `__libc_heap_limit`. The heap begins at `_end` and ends
`__libc_heap_limit` bytes afterwards. This prevents a completely unused
heap from requiring any space, and it prevents the heap from being
zeroed at initialization time as part of BSS. It also allows users to
customize the available heap location without recompiling libc.
I'd think this should eventually be replaced with an implemenation based
on a morecore() library. This would allow the same implementation to use
sbrk() on POSIX, `_end` and `__libc_heap_limit` on embedded, and a
buffer in tests. It would also provide better "wilderness" behavior that
tends to decrease heap fragementation (see Wilson et al.)
See #98096
Summary:
This file is an object library, but uses the `LIBC_COPT_PUBLIC_PACKAING`
option. This will always be undefined which leads to a type mismatch
when uses actually try to link against it. This patch simply removes
this and turns it into a header only library. This means that the
implementations of the callback lists and the mutexes need to live in
their respective files. The result is that `atexit` needs to be defined
for `at_quick_exit` to be valid.
This patch makes rand select different algorithms depending on the arch.
This is needed to avoid a test failure in 32-bit systems where the LSB
of rand was not uniform enough when the 64-bit constants are used in
32-bit systems.
Atexit needs to be linked into exit on linux since atexit defines
__cxa_finalize. This should probably be fixed a different way but this
works for now.
These are not required and without these dependencies, we would wound up
with an unresolved reference to __cxa_finalize, which can be provided by
the vendor making this compatible with baremetal.
This adds support for aligned_alloc with the freelist allocator. This
works by finding blocks large enough to hold the requested size plus
some shift amount that's at most the requested alignment. Blocks that
meet this requirement but aren't properly aligned can be split such that
the usable_space of a new block is aligned properly. The "padding" block
created will be merged with the previous block if one exists.
Summary:
These warnings mean that it will lower to a libcall. Previously we just
disabled it locally, which didn't work with GCC. This patch does it
globally in the compiler options if the compiler is clang.
Summary:
I initially didn't report these as supported because they didn't provide
expected behavior and were very wasteful. The recent patch moved them to
a lock-free atomic implementation so they can now actually be used.
Summary:
This function uses atomics now, which emit warnings on some platforms
that don't support full lock-free atomics. These aren't specifically
wrong, and in the future we could investigate a libc configuration
specialized for single-threaded microprocessors, but for now we should
get the bot running again.
Summary:
Currently, we implement the `rand` function using thread-local storage.
This is somewhat problematic because not every target supports TLS, and
even more do not support non-zero initializers on TLS.
The C standard states that the `rand()` function need not be thread,
safe. However, many implementations provide thread-safety anyway.
There's some confusing language in the 'rationale' section of
https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html,
but given that `glibc` uses a lock, I think we should make this thread
safe as well. it mentions that threaded behavior is desirable and can be
done in the two ways:
1. A single per-process sequence of pseudo-random numbers that is shared
by all threads that call rand()
2. A different sequence of pseudo-random numbers for each thread that
calls rand()
The current implementation is (2.) and this patch moves it to (1.). This
is beneficial for the GPU case and more generic support. The downside is
that it's slightly slower to do these atomic operations, the fast path
will be two atomic reads and an atomic write.
Rather than propgating a compile define, add an explicit cmake flag for
controlling the size. The default for baremetal is 100KB and the default
for others is 1GB.
This refactors some of the FreeListHeap, FreeList, and Block classes to
have constexpr ctors so we can constinit a global allocator that does
not require running some global function or global ctor to initialize.
This is needed to prevent worrying about initialization order and any
other module-ctor can invoke malloc without worry.
This is the actual freelist allocator which utilizes the generic
FreeList and the Block classes. We will eventually wrap the malloc
interface around this.
This is a part of #94270 to land in smaller patches.
