fluencelabs/musl
1
0
Fork 0
mirror of https://github.com/fluencelabs/musl synced 2025-06-25 04:31:56 +00:00
Code Issues Projects Releases Wiki Activity
Files
e803829e6b087c0ed91adc11f87185109bc59b31
musl/src/internal/libc.h

75 lines
1.5 KiB
C
Raw Normal View History

initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
#ifndef LIBC_H
#define LIBC_H
#include <stdlib.h>
#include <stdio.h>
support configurable page size on mips, powerpc and microblaze PAGE_SIZE was hardcoded to 4096, which is historically what most systems use, but on several archs it is a kernel config parameter, user space can only know it at execution time from the aux vector. PAGE_SIZE and PAGESIZE are not defined on archs where page size is a runtime parameter, applications should use sysconf(_SC_PAGE_SIZE) to query it. Internally libc code defines PAGE_SIZE to libc.page_size, which is set to aux[AT_PAGESZ] in __init_libc and early in __dynlink as well. (Note that libc.page_size can be accessed without GOT, ie. before relocations are done) Some fpathconf settings are hardcoded to 4096, these should be actually queried from the filesystem using statfs.
2013-09-15 02:00:32 +00:00
#include <limits.h>
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
use an accessor function for __libc data pointer when compiled as PIC prior to this change, a large portion of libc was unusable prior to relocation by the dynamic linker, due to dependence on the global data in the __libc structure and the need to obtain its address through the GOT. with this patch, the accessor function __libc_loc is now able to obtain the address of __libc via PC-relative addressing without using the GOT. this means the majority of libc functionality is now accessible right away. naturally, the above statements all depend on having an architecture where PC-relative addressing and jumps/calls are feasible, and a compiler that generates the appropriate code.
2011-02-20 22:30:06 -05:00
struct __libc {
simplify multi-threaded errno, eliminate useless function pointer
2011-08-06 20:20:23 -04:00
void *main_thread;
clean up handling of thread/nothread mode, locking
2011-04-17 16:53:54 -04:00
int threaded;
security hardening: ensure suid programs have valid stdin/out/err this behavior (opening fds 0-2 for a suid program) is explicitly allowed (but not required) by POSIX to protect badly-written suid programs from clobbering files they later open. this commit does add some cost in startup code, but the availability of auxv and the security flag will be useful elsewhere in the future. in particular auxv is needed for static-linked vdso support, which is still waiting to be committed (sorry nik!)
2011-08-23 09:37:39 -04:00
int secure;
size_t *auxv;
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
volatile int threads_minus_1;
security hardening: ensure suid programs have valid stdin/out/err this behavior (opening fds 0-2 for a suid program) is explicitly allowed (but not required) by POSIX to protect badly-written suid programs from clobbering files they later open. this commit does add some cost in startup code, but the availability of auxv and the security flag will be useful elsewhere in the future. in particular auxv is needed for static-linked vdso support, which is still waiting to be committed (sorry nik!)
2011-08-23 09:37:39 -04:00
int canceldisable;
implement flockfile api, rework stdio locking
2011-03-12 21:55:45 -05:00
FILE *ofl_head;
ditch the priority inheritance locks; use malloc's version of lock i did some testing trying to switch malloc to use the new internal lock with priority inheritance, and my malloc contention test got 20-100 times slower. if priority inheritance futexes are this slow, it's simply too high a price to pay for avoiding priority inversion. maybe we can consider them somewhere down the road once the kernel folks get their act together on this (and perferably don't link it to glibc's inefficient lock API)... as such, i've switch __lock to use malloc's implementation of lightweight locks, and updated all the users of the code to use an array with a waiter count for their locks. this should give optimal performance in the vast majority of cases, and it's simple. malloc is still using its own internal copy of the lock code because it seems to yield measurably better performance with -O3 when it's inlined (20% or more difference in the contention stress test).
2012-04-24 16:32:23 -04:00
int ofl_lock[2];
support for TLS in dynamic-loaded (dlopen) modules unlike other implementations, this one reserves memory for new TLS in all pre-existing threads at dlopen-time, and dlopen will fail with no resources consumed and no new libraries loaded if memory is not available. memory is not immediately distributed to running threads; that would be too complex and too costly. instead, assurances are made that threads needing the new TLS can obtain it in an async-signal-safe way from a buffer belonging to the dynamic linker/new module (via atomic fetch-and-add based allocator). I've re-appropriated the lock that was previously used for __synccall (synchronizing set*id() syscalls between threads) as a general pthread_create lock. it's a "backwards" rwlock where the "read" operation is safe atomic modification of the live thread count, which multiple threads can perform at the same time, and the "write" operation is making sure the count does not increase during an operation that depends on it remaining bounded (__synccall or dlopen). in static-linked programs that don't use __synccall, this lock is a no-op and has no cost.
2012-10-05 11:51:50 -04:00
size_t tls_size;
support configurable page size on mips, powerpc and microblaze PAGE_SIZE was hardcoded to 4096, which is historically what most systems use, but on several archs it is a kernel config parameter, user space can only know it at execution time from the aux vector. PAGE_SIZE and PAGESIZE are not defined on archs where page size is a runtime parameter, applications should use sysconf(_SC_PAGE_SIZE) to query it. Internally libc code defines PAGE_SIZE to libc.page_size, which is set to aux[AT_PAGESZ] in __init_libc and early in __dynlink as well. (Note that libc.page_size can be accessed without GOT, ie. before relocations are done) Some fpathconf settings are hardcoded to 4096, these should be actually queried from the filesystem using statfs.
2013-09-15 02:00:32 +00:00
size_t page_size;
use an accessor function for __libc data pointer when compiled as PIC prior to this change, a large portion of libc was unusable prior to relocation by the dynamic linker, due to dependence on the global data in the __libc structure and the need to obtain its address through the GOT. with this patch, the accessor function __libc_loc is now able to obtain the address of __libc via PC-relative addressing without using the GOT. this means the majority of libc functionality is now accessible right away. naturally, the above statements all depend on having an architecture where PC-relative addressing and jumps/calls are feasible, and a compiler that generates the appropriate code.
2011-02-20 22:30:06 -05:00
};
save AT_HWCAP from auxv for subsequent use in machine-specific code it's expected that this will be needed/useful only in asm, so I've given it its own symbol that can be addressed in pc-relative ways from asm rather than adding a field in the __libc structure which would require hard-coding the offset wherever it's used.
2012-07-27 00:14:57 -04:00
extern size_t __hwcap;
various changes in preparation for dynamic linking support prefer using visibility=hidden for __libc internal data, rather than an accessor function, if the compiler has visibility. optimize with -O3 for PIC targets (shared library). without heavy inlining, reloading the GOT register in small functions kills performance. 20-30% size increase for a single libc.so is not a big deal, compared to comparaible size increase in every static binaries. use -Bsymbolic-functions, not -Bsymbolic. global variables are subject to COPY relocations, and thus binding their addresses in the library at link time will cause library functions to read the wrong (original) copies instead of the copies made in the main program's bss section. add entry point, _start, for dynamic linker.
2011-02-24 16:37:21 -05:00
support configurable page size on mips, powerpc and microblaze PAGE_SIZE was hardcoded to 4096, which is historically what most systems use, but on several archs it is a kernel config parameter, user space can only know it at execution time from the aux vector. PAGE_SIZE and PAGESIZE are not defined on archs where page size is a runtime parameter, applications should use sysconf(_SC_PAGE_SIZE) to query it. Internally libc code defines PAGE_SIZE to libc.page_size, which is set to aux[AT_PAGESZ] in __init_libc and early in __dynlink as well. (Note that libc.page_size can be accessed without GOT, ie. before relocations are done) Some fpathconf settings are hardcoded to 4096, these should be actually queried from the filesystem using statfs.
2013-09-15 02:00:32 +00:00
#ifndef PAGE_SIZE
#define PAGE_SIZE libc.page_size
#endif
workaround broken hidden-visibility handling in pcc with this change, pcc-built musl libc.so seems to work correctly. the problem is that pcc generates GOT lookups for external-linkage symbols even if they are hidden, rather than using GOT-relative addressing. the entire reason we're using hidden visibility on the __libc object is to make it accessible prior to relocations -- not to mention inexpensive to access. unfortunately, the workaround makes it even more expensive on pcc. when the pcc issue is fixed, an appropriate version test should be added so new pcc can use the much more efficient variant.
2012-10-13 23:53:18 -04:00
#if !defined(__PIC__) || (100*__GNUC__+__GNUC_MINOR__ >= 303 && !defined(__PCC__))
various changes in preparation for dynamic linking support prefer using visibility=hidden for __libc internal data, rather than an accessor function, if the compiler has visibility. optimize with -O3 for PIC targets (shared library). without heavy inlining, reloading the GOT register in small functions kills performance. 20-30% size increase for a single libc.so is not a big deal, compared to comparaible size increase in every static binaries. use -Bsymbolic-functions, not -Bsymbolic. global variables are subject to COPY relocations, and thus binding their addresses in the library at link time will cause library functions to read the wrong (original) copies instead of the copies made in the main program's bss section. add entry point, _start, for dynamic linker.
2011-02-24 16:37:21 -05:00
cleanup and work around visibility bug in gcc 3 that affects x86_64 in gcc 3, the visibility attribute must be placed on both the declaration and on the definition. if it's omitted from the definition, the compiler fails to emit the ".hidden" directive in the assembly, and the linker will either generate textrels (if supported, such as on i386) or refuse to link (on targets where certain types of textrels are forbidden or impossible without further assumptions about memory layout, such as on x86_64). this patch also unifies the decision about when to use visibility into libc.h and makes the visibility in the utf-8 state machine tables based on libc.h rather than a duplicate test.
2012-02-23 21:24:56 -05:00
#ifdef __PIC__
new attempt at working around the gcc 3 visibility bug since gcc is failing to generate the necessary ".hidden" directive in the output asm, generate it explicitly with an __asm__ statement...
2012-02-24 20:07:21 -05:00
#if __GNUC__ < 4
#define BROKEN_VISIBILITY 1
#endif
fix trailing whitespace issues that crept in here and there
2012-12-07 16:16:44 -05:00
#define ATTR_LIBC_VISIBILITY __attribute__((visibility("hidden")))
cleanup and work around visibility bug in gcc 3 that affects x86_64 in gcc 3, the visibility attribute must be placed on both the declaration and on the definition. if it's omitted from the definition, the compiler fails to emit the ".hidden" directive in the assembly, and the linker will either generate textrels (if supported, such as on i386) or refuse to link (on targets where certain types of textrels are forbidden or impossible without further assumptions about memory layout, such as on x86_64). this patch also unifies the decision about when to use visibility into libc.h and makes the visibility in the utf-8 state machine tables based on libc.h rather than a duplicate test.
2012-02-23 21:24:56 -05:00
#else
#define ATTR_LIBC_VISIBILITY
#endif
extern struct __libc __libc ATTR_LIBC_VISIBILITY;
use an accessor function for __libc data pointer when compiled as PIC prior to this change, a large portion of libc was unusable prior to relocation by the dynamic linker, due to dependence on the global data in the __libc structure and the need to obtain its address through the GOT. with this patch, the accessor function __libc_loc is now able to obtain the address of __libc via PC-relative addressing without using the GOT. this means the majority of libc functionality is now accessible right away. naturally, the above statements all depend on having an architecture where PC-relative addressing and jumps/calls are feasible, and a compiler that generates the appropriate code.
2011-02-20 22:30:06 -05:00
#define libc __libc
various changes in preparation for dynamic linking support prefer using visibility=hidden for __libc internal data, rather than an accessor function, if the compiler has visibility. optimize with -O3 for PIC targets (shared library). without heavy inlining, reloading the GOT register in small functions kills performance. 20-30% size increase for a single libc.so is not a big deal, compared to comparaible size increase in every static binaries. use -Bsymbolic-functions, not -Bsymbolic. global variables are subject to COPY relocations, and thus binding their addresses in the library at link time will cause library functions to read the wrong (original) copies instead of the copies made in the main program's bss section. add entry point, _start, for dynamic linker.
2011-02-24 16:37:21 -05:00
#else
cleanup and work around visibility bug in gcc 3 that affects x86_64 in gcc 3, the visibility attribute must be placed on both the declaration and on the definition. if it's omitted from the definition, the compiler fails to emit the ".hidden" directive in the assembly, and the linker will either generate textrels (if supported, such as on i386) or refuse to link (on targets where certain types of textrels are forbidden or impossible without further assumptions about memory layout, such as on x86_64). this patch also unifies the decision about when to use visibility into libc.h and makes the visibility in the utf-8 state machine tables based on libc.h rather than a duplicate test.
2012-02-23 21:24:56 -05:00
various changes in preparation for dynamic linking support prefer using visibility=hidden for __libc internal data, rather than an accessor function, if the compiler has visibility. optimize with -O3 for PIC targets (shared library). without heavy inlining, reloading the GOT register in small functions kills performance. 20-30% size increase for a single libc.so is not a big deal, compared to comparaible size increase in every static binaries. use -Bsymbolic-functions, not -Bsymbolic. global variables are subject to COPY relocations, and thus binding their addresses in the library at link time will cause library functions to read the wrong (original) copies instead of the copies made in the main program's bss section. add entry point, _start, for dynamic linker.
2011-02-24 16:37:21 -05:00
#define USE_LIBC_ACCESSOR
cleanup and work around visibility bug in gcc 3 that affects x86_64 in gcc 3, the visibility attribute must be placed on both the declaration and on the definition. if it's omitted from the definition, the compiler fails to emit the ".hidden" directive in the assembly, and the linker will either generate textrels (if supported, such as on i386) or refuse to link (on targets where certain types of textrels are forbidden or impossible without further assumptions about memory layout, such as on x86_64). this patch also unifies the decision about when to use visibility into libc.h and makes the visibility in the utf-8 state machine tables based on libc.h rather than a duplicate test.
2012-02-23 21:24:56 -05:00
#define ATTR_LIBC_VISIBILITY
various changes in preparation for dynamic linking support prefer using visibility=hidden for __libc internal data, rather than an accessor function, if the compiler has visibility. optimize with -O3 for PIC targets (shared library). without heavy inlining, reloading the GOT register in small functions kills performance. 20-30% size increase for a single libc.so is not a big deal, compared to comparaible size increase in every static binaries. use -Bsymbolic-functions, not -Bsymbolic. global variables are subject to COPY relocations, and thus binding their addresses in the library at link time will cause library functions to read the wrong (original) copies instead of the copies made in the main program's bss section. add entry point, _start, for dynamic linker.
2011-02-24 16:37:21 -05:00
extern struct __libc *__libc_loc(void) __attribute__((const));
#define libc (*__libc_loc())
use an accessor function for __libc data pointer when compiled as PIC prior to this change, a large portion of libc was unusable prior to relocation by the dynamic linker, due to dependence on the global data in the __libc structure and the need to obtain its address through the GOT. with this patch, the accessor function __libc_loc is now able to obtain the address of __libc via PC-relative addressing without using the GOT. this means the majority of libc functionality is now accessible right away. naturally, the above statements all depend on having an architecture where PC-relative addressing and jumps/calls are feasible, and a compiler that generates the appropriate code.
2011-02-20 22:30:06 -05:00
#endif
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
/* Designed to avoid any overhead in non-threaded processes */
use explicit visibility to optimize a few hot-path function calls on x86 and some other archs, functions which make function calls which might go through a PLT incur a significant overhead cost loading the GOT register prior to making the call. this load is utterly useless in musl, since all calls are bound at library-creation time using -Bsymbolic-functions, but the compiler has no way of knowing this, and attempts to set the default visibility to protected have failed due to bugs in GCC and binutils. this commit simply manually assigns hidden/protected visibility, as appropriate, to a few internal-use-only functions which have many callers, or which have callers that are hot paths like getc/putc. it shaves about 5k off the i386 libc.so with -Os. many of the improvements are in syscall wrappers, where the benefit is just size and performance improvement is unmeasurable noise amid the syscall overhead. however, stdio may be measurably faster. if in the future there are toolchains that can do the same thing globally without introducing linking bugs, it might be worth considering removing these workarounds.
2012-10-25 15:40:58 -04:00
void __lock(volatile int *) ATTR_LIBC_VISIBILITY;
void __unlock(volatile int *) ATTR_LIBC_VISIBILITY;
int __lockfile(FILE *) ATTR_LIBC_VISIBILITY;
void __unlockfile(FILE *) ATTR_LIBC_VISIBILITY;
fix potential deadlock bug in libc-internal locking logic if a multithreaded program became non-multithreaded (i.e. all other threads exited) while one thread held an internal lock, the remaining thread would fail to release the lock. the the program then became multithreaded again at a later time, any further attempts to obtain the lock would deadlock permanently. the underlying cause is that the value of libc.threads_minus_1 at unlock time might not match the value at lock time. one solution would be returning a flag to the caller indicating whether the lock was taken and needs to be unlocked, but there is a simpler solution: using the lock itself as such a flag. note that this flag is not needed anyway for correctness; if the lock is not held, the unlock code is harmless. however, the memory synchronization properties associated with a_store are costly on some archs, so it's best to avoid executing the unlock code when it is unnecessary.
2013-09-20 02:00:27 -04:00
#define LOCK(x) __lock(x)
#define UNLOCK(x) __unlock(x)
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
new attempt at making set*id() safe and robust changing credentials in a multi-threaded program is extremely difficult on linux because it requires synchronizing the change between all threads, which have their own thread-local credentials on the kernel side. this is further complicated by the fact that changing the real uid can fail due to exceeding RLIMIT_NPROC, making it possible that the syscall will succeed in some threads but fail in others. the old __rsyscall approach being replaced was robust in that it would report failure if any one thread failed, but in this case, the program would be left in an inconsistent state where individual threads might have different uid. (this was not as bad as glibc, which would sometimes even fail to report the failure entirely!) the new approach being committed refuses to change real user id when it cannot temporarily set the rlimit to infinity. this is completely POSIX conformant since POSIX does not require an implementation to allow real-user-id changes for non-privileged processes whatsoever. still, setting the real uid can fail due to memory allocation in the kernel, but this can only happen if there is not already a cached object for the target user. thus, we forcibly serialize the syscalls attempts, and fail the entire operation on the first failure. this *should* lead to an all-or-nothing success/failure result, but it's still fragile and highly dependent on kernel developers not breaking things worse than they're already broken. ideally linux will eventually add a CLONE_USERCRED flag that would give POSIX conformant credential changes without any hacks from userspace, and all of this code would become redundant and could be removed ~10 years down the line when everyone has abandoned the old broken kernels. i'm not holding my breath...
2011-07-29 22:59:44 -04:00
void __synccall(void (*)(void *), void *);
int __setxid(int, int, int, int);
move rsyscall out of pthread_create module this is something of a tradeoff, as now set*id() functions, rather than pthread_create, are what pull in the code overhead for dealing with linux's refusal to implement proper POSIX thread-vs-process semantics. my motivations are: 1. it's cleaner this way, especially cleaner to optimize out the rsyscall locking overhead from pthread_create when it's not needed. 2. it's expected that only a tiny number of core system programs will ever use set*id() functions, whereas many programs may want to use threads, and making thread overhead tiny is an incentive for "light" programs to try threads.
2011-04-06 20:27:07 -04:00
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
extern char **__environ;
#undef weak_alias
#define weak_alias(old, new) \
extern __typeof(old) new __attribute__((weak, alias(#old)))
#undef LFS64_2
enable LARGEFILE64 aliases these will NOT be used when compiling with -D_LARGEFILE64_SOURCE on musl; instead, they exist in the hopes of eventually being able to run some glibc-linked apps with musl sitting in place of glibc. also remove the (apparently incorrect) fcntl alias.
2012-05-31 23:12:31 -04:00
#define LFS64_2(x, y) weak_alias(x, y)
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
#undef LFS64
#define LFS64(x) LFS64_2(x, x##64)
#endif
Reference in New Issue Copy Permalink