If we are sorting something that is a multiple of sizeof(void*), we have
to ensure that we swap one pointer at a time since swapping using
sub-pointer-size stores invalidate the pointers (pointers have a hidden
validity tags that is invalidated when performing non-monotonic
operations such as storing only part of the pointers).
While touching this code also use G_ALIGNOF() instead of a macro that
is generated at configure time.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
We have to ensure that the memory location is sufficiently aligned to
store any object. This unbreaks the code for CHERI where using gsize
results in values that are only aligned to 8 bytes, but we need 16 byte
alignment for pointers. This is fully API/ABI compatible since amount
of padding before the actual allocation does not change for existing
architectures, only for CHERI.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
LLVM objcopy's --strip-all is more aggressive that GNU objcopy --strip-all
and will remove everything that is not actually used. In this case we
see the following error:
`error: 'gio/tests/test_resources.o': Symbol table has link index of 5 which is not a valid index`
Fix this by only removing debug symbols instead of all unused symbols and
sections.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
Unlike GNU ld which has a default target architecture, ld.lld is always a
cross-linker and has the same behaviour for all targets. If you don't tell
ld.lld what the target architecture is it can't infer the right ELF flags
for the resulting object file.
```
$ ~/cheri/output/sdk/bin/ld -r -b binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
LLD 14.0.0 (compatible with GNU linkers)
ld: error: target emulation unknown: -m or at least one .o file required
```
As you can see from the error message it can't infer the target
architecture (you need a least one valid .o file or the -m flag).
If you use the compiler instead of directly invoking the linker it will
pass the appropriate flags:
```
$ ~/cheri/output/sdk/bin/clang -r -Wl,-b,binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
clang version 14.0.0 (https://github.com/CTSRD-CHERI/llvm-project.git ff66b683475fc44355b2010dbcbe1202d785e6f8)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/alexrichardson/cheri/output/sdk/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/home/alexrichardson/cheri/output/sdk/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o gio/tests/test_resources.o -L/usr/lib/gcc/x86_64-linux-gnu/12 -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/home/alexrichardson/cheri/output/sdk/bin/../lib -L/lib -L/usr/lib -r -b binary gio/tests/test5.gresource
❯ file gio/tests/test_resources.o
gio/tests/test_resources.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
```
This works for most architectures, but ones that need additional metadata
sections to encode the used ABI, etc. will require a different approach
using .incbin. However, that is a change for another MR.
Partially fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
In case the OS does not support epoll and kqueue, we get the warning:
gio/tests/pollable.c: In function ‘test_pollable_unix_nulldev’:
gio/tests/pollable.c:266:7: warning: unused variable ‘fd’
[-Wunused-variable]
266 | int fd;
Get rid of it.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Since commit 94b658ab4c, gwakeup.c has
started using C99 integer types, but has not included <stdint.h>. This
broke building on GNU/Hurd. Fix this by adding the missing include.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
...much like g_string_free_and_steal () does; by redirecting
g_string_free (_, FALSE) calls (when we can detect them) to
g_string_free_and_steal ().
This relies on some unpretty macros, but should be entirely transparent
to any users of g_string_free (). In particular, the macro only
evaluates its arguments once, no matter which branch ends up being
taken. The ternary operator the macro expands to always gets optimized
out, even at -O0: there is only one call to either g_string_free () or
g_string_free_and_steal () in the compiled code, with no run-time
branching.
Add a test for ensuring this works as expected in C++ too.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Now that there is g_string_free_and_steal (), we can use it instead of
the older g_string_free (_, FALSE). Make sure to use its return value
while doing so, as opposed to manually accessing string->str, to avoid
compiler warnings and make the intent more explicit.
This is all done in preparation for making g_string_free (_, FALSE) warn
on unused return value much like g_string_free_and_steal (), which will
happen in the next commit.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
g_strdup() is often used to duplicate static strings, in these cases the
compiler could use a faster path because it knows the length of the
string at compile time, but this cannot happen because our g_strdup()
implementation is hidden.
To improve this case, we add a simple implementation of g_strdup() when
it is used with static or NULL strings that explicitly uses strlen,
g_malloc and memcpy to give hints to the compiler how to behave better.
This has definitely some benefits in terms of performances, causing an
iteration of 1000000 string duplication to drop from 2.7002s to 1.9428s
for a static string and from ~0.6584s to ~0.4408 for a NULL one.
Since compiler can optimize these cases quite a bit, the generated code
[2] is not increasing a lot, given that it can now avoid generating some
code or do it in few simpler steps.
Update tests to cover both inlined and non inlined cases.
[1] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3209#note_1644383
[2] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3209#note_1646662
We have actual definitions for these functions so we should ignore their
inline versions, not to potentially break doc parsers due to the different
argument names.
For some reasons we can't merge the check together with the gnu C check
if, otherwise the check gets ignored by doc parser.
Spawning a process correctly is a lot more complicated than just bunging
an argument onto the return value from this function.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2901
We could have unguarded crashes when calling strlen (NULL) or when passing
invalid GString's.
Also ensure that we are not using the macro `val` argument multiple times as
it may lead to an unwanted behavior when passing to it a variable value such
as `str[++i]`, as the value may be called multiple times.
C++ tests and Coverity were both underlining this.
Fixes: #2890
Now that the implementation of GSlice has been dropped, these tests for
the internals of the implementation are unnecessary.
We can keep `glib/tests/slice.c` as it tests the API rather than the
implementation.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1079
Keep the API for ABI compatibility.
See
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2935#note_1650099
for a summary of the reasoning for this change:
- The performance of system-provided allocators has improved since
GSlice was written, and they are now similarly as performant, or more
performant, than GSlice.
- The code is unmaintained and nobody understands it.
- It doesn’t integrate with tooling and system security features which
have been written for the system `malloc()` implementation (such as
sanitisers, valgrind, etc.).
- It’s confusing for developers: should they use `g_slice_new()` or
`g_new()`?
- GSlice is faster than the libc allocator for allocating and
(particularly) freeing linked lists, but since these are a rubbish
data structure, that’s not a great thing to optimise for.
For the cases where application performance is negatively impacted by
the implementation of GSlice being dropped (and we don’t think there’ll
be many), applications can use a drop-in `malloc()` replacement which is
more suited to their particular workload. Choosing an allocator in GLib
to suit all application workloads is not possible.
Including documentation updates and cleanups by Philip Withnall.
Fixes: #1079
