fluencelabs/musl
1
0
Fork 0
mirror of https://github.com/fluencelabs/musl synced 2025-06-25 12:42:02 +00:00
Code Issues Projects Releases Wiki Activity
Files
c0f344160d22d889460573d003cf349626a38184
musl/src/internal/libc.h

62 lines
1.3 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>
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;
int canceldisable;
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
int (*atexit)(void (*)(void));
void (*fini)(void);
void (*ldso_fini)(void);
volatile int threads_minus_1;
reorganize the __libc structure for threaded performance issues we want to keep atomically updated fields (locks and thread count) and really anything writable far away from frequently-needed function pointers. stuff some rarely-needed function pointers in between to pad, hopefully up to a cache line boundary.
2011-04-01 22:35:20 -04:00
int ofl_lock;
implement flockfile api, rework stdio locking
2011-03-12 21:55:45 -05:00
FILE *ofl_head;
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
};
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
#if 100*__GNUC__+__GNUC_MINOR__ >= 303 || defined(__PCC__) || defined(__TINYC__)
extern struct __libc __libc __attribute__((visibility("hidden")));
#define libc __libc
#elif !defined(__PIC__)
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
extern struct __libc __libc;
#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
#define USE_LIBC_ACCESSOR
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 */
void __lock(volatile int *);
add proper fuxed-based locking for stdio previously, stdio used spinlocks, which would be unacceptable if we ever add support for thread priorities, and which yielded pathologically bad performance if an application attempted to use flockfile on a key file as a major/primary locking mechanism. i had held off on making this change for fear that it would hurt performance in the non-threaded case, but actually support for recursive locking had already inflicted that cost. by having the internal locking functions store a flag indicating whether they need to perform unlocking, rather than using the actual recursive lock counter, i was able to combine the conditionals at unlock time, eliminating any additional cost, and also avoid a nasty corner case where a huge number of calls to ftrylockfile could cause deadlock later at the point of internal locking. this commit also fixes some issues with usage of pthread_self conflicting with __attribute__((const)) which resulted in crashes with some compiler versions/optimizations, mainly in flockfile prior to pthread_create.
2011-07-30 08:02:14 -04:00
int __lockfile(FILE *);
void __unlockfile(FILE *);
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
#define LOCK(x) (libc.threads_minus_1 ? (__lock(x),1) : ((void)(x),1))
clean up handling of thread/nothread mode, locking
2011-04-17 16:53:54 -04:00
#define UNLOCK(x) (*(volatile int *)(x)=0)
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 *);
pthread and synccall cleanup, new __synccall_wait op fix up clone signature to match the actual behavior. the new __syncall_wait function allows a __synccall callback to wait for other threads to continue without returning, so that it can resume action after the caller finishes. this interface could be made significantly more general/powerful with minimal effort, but i'll wait to do that until it's actually useful for something.
2011-08-12 10:32:22 -04:00
void __synccall_wait(void);
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
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;
#define environ __environ
#undef weak_alias
#define weak_alias(old, new) \
extern __typeof(old) new __attribute__((weak, alias(#old)))
#undef LFS64_2
//#define LFS64_2(x, y) weak_alias(x, y)
#define LFS64_2(x, y) extern __typeof(x) y
#undef LFS64
#define LFS64(x) LFS64_2(x, x##64)
#endif
Reference in New Issue Copy Permalink