about summary refs log tree commit diff
path: root/src/env
Commit message (Collapse)AuthorAgeFilesLines
* fix #ifdef inside a macro argument list in __init_tls.cSzabolcs Nagy2014-08-131-4/+3
| | | | | C99 6.10.3p11 disallows such constructs so use an #ifdef outside of the argument list of __syscall
* eliminate use of cached pid from thread structureRich Felker2014-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | the main motivation for this change is to remove the assumption that the tid of the main thread is also the pid of the process. (the value returned by the set_tid_address syscall was used to fill both fields despite it semantically being the tid.) this is historically and presently true on linux and unlikely to change, but it conceivably could be false on other systems that otherwise reproduce the linux syscall api/abi. only a few parts of the code were actually still using the cached pid. in a couple places (aio and synccall) it was a minor optimization to avoid a syscall. caching could be reintroduced, but lazily as part of the public getpid function rather than at program startup, if it's deemed important for performance later. in other places (cancellation and pthread_kill) the pid was completely unnecessary; the tkill syscall can be used instead of tgkill. this is actually a rather subtle issue, since tgkill is supposedly a solution to race conditions that can affect use of tkill. however, as documented in the commit message for commit 7779dbd2663269b465951189b4f43e70839bc073, tgkill does not actually solve this race; it just limits it to happening within one process rather than between processes. we use a lock that avoids the race in pthread_kill, and the use in the cancellation signal handler is self-targeted and thus not subject to tid reuse races, so both are safe regardless of which syscall (tgkill or tkill) is used.
* add locale frameworkRich Felker2014-07-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | this commit adds non-stub implementations of setlocale, duplocale, newlocale, and uselocale, along with the data structures and minimal code needed for representing the active locale on a per-thread basis and optimizing the common case where thread-local locale settings are not in use. at this point, the data structures only contain what is necessary to represent LC_CTYPE (a single flag) and LC_MESSAGES (a name for use in finding message translation files). representation for the other categories will be added later; the expectation is that a single pointer will suffice for each. for LC_CTYPE, the strings "C" and "POSIX" are treated as special; any other string is accepted and treated as "C.UTF-8". for other categories, any string is accepted after being truncated to a maximum supported length (currently 15 bytes). for LC_MESSAGES, the name is kept regardless of whether libc itself can use such a message translation locale, since applications using catgets or gettext should be able to use message locales libc is not aware of. for other categories, names which are not successfully loaded as locales (which, at present, means all names) are treated as aliases for "C". setlocale never fails. locale settings are not yet used anywhere, so this commit should have no visible effects except for the contents of the string returned by setlocale.
* fix typo in a comment in __libc_start_mainRich Felker2014-07-011-1/+1
|
* separate __tls_get_addr implementation from dynamic linker/init_tlsRich Felker2014-06-191-5/+0
| | | | | | | | | | | | | | | such separation serves multiple purposes: - by having the common path for __tls_get_addr alone in its own function with a tail call to the slow case, code generation is greatly improved. - by having __tls_get_addr in it own file, it can be replaced on a per-arch basis as needed, for optimization or ABI-specific purposes. - by removing __tls_get_addr from __init_tls.c, a few bytes of code are shaved off of static binaries (which are unlikely to use this function unless the linker messed up).
* simplify errno implementationRich Felker2014-06-101-1/+0
| | | | | | | | | | | | | | | the motivation for the errno_ptr field in the thread structure, which this commit removes, was to allow the main thread's errno to keep its address when lazy thread pointer initialization was used. &errno was evaluated prior to setting up the thread pointer and stored in errno_ptr for the main thread; subsequently created threads would have errno_ptr pointing to their own errno_val in the thread structure. since lazy initialization was removed, there is no need for this extra level of indirection; __errno_location can simply return the address of the thread's errno_val directly. this does cause &errno to change, but the change happens before entry to application code, and thus is not observable.
* add thread-pointer support for pre-2.6 kernels on i386Rich Felker2014-06-101-9/+4
| | | | | | | | | | | | | | | | | | | such kernels cannot support threads, but the thread pointer is also important for other purposes, most notably stack protector. without a valid thread pointer, all code compiled with stack protector will crash. the same applies to any use of thread-local storage by applications or libraries. the concept of this patch is to fall back to using the modify_ldt syscall, which has been around since linux 1.0, to setup the gs segment register. since the kernel does not have a way to automatically assign ldt entries, use of slot zero is hard-coded. if this fallback path is used, __set_thread_area returns a positive value (rather than the usual zero for success, or negative for error) indicating to the caller that the thread pointer was successfully set, but only for the main thread, and that thread creation will not work properly. the code in __init_tp has been changed accordingly to record this result for later use by pthread_create.
* support linux kernel apis (new archs) with old syscalls removedRich Felker2014-05-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | such archs are expected to omit definitions of the SYS_* macros for syscalls their kernels lack from arch/$ARCH/bits/syscall.h. the preprocessor is then able to select the an appropriate implementation for affected functions. two basic strategies are used on a case-by-case basis: where the old syscalls correspond to deprecated library-level functions, the deprecated functions have been converted to wrappers for the modern function, and the modern function has fallback code (omitted at the preprocessor level on new archs) to make use of the old syscalls if the new syscall fails with ENOSYS. this also improves functionality on older kernels and eliminates the incentive to program with deprecated library-level functions for the sake of compatibility with older kernels. in other situations where the old syscalls correspond to library-level functions which are not deprecated but merely lack some new features, such as the *at functions, the old syscalls are still used on archs which support them. this may change at some point in the future if or when fallback code is added to the new functions to make them usable (possibly with reduced functionality) on old kernels.
* support kernels with no SYS_open syscall, only SYS_openatRich Felker2014-05-241-1/+1
| | | | | | | | | | open is handled specially because it is used from so many places, in so many variants (2 or 3 arguments, setting errno or not, and cancellable or not). trying to do it as a function would not only increase bloat, but would also risk subtle breakage. this is the first step towards supporting "new" archs where linux lacks "old" syscalls.
* make __init_libc static for non-shared libcRich Felker2014-04-211-0/+3
| | | | | | | being static allows it to be inlined in __libc_start_main; inlining should take place at all levels since the function is called exactly once. this further reduces mandatory startup code size for static binaries.
* further micro-optimize startup code for sizeRich Felker2014-04-212-23/+14
| | | | | | there is no reason (and seemingly there never was any) for __init_security to be its own function. it's linked unconditionally so it can just be placed inline in __init_libc.
* micro-optimize some startup code for sizeRich Felker2014-04-212-7/+4
| | | | | | | | | | | moving the call to __init_ssp from __init_security to __init_libc makes __init_security a leaf function, which allows the compiler to make it smaller. __init_libc is already non-leaf, and the additional call makes no difference to the amount of register spillage. in addition, it really made no sense for the call to __init_ssp to be buried inside __init_security rather than parallel with other init functions.
* remove some cruft from libc/tls init codeRich Felker2014-04-072-3/+0
|
* remove cruft left behind when lazy thread pointer init was removedRich Felker2014-04-041-8/+0
| | | | | | | the function itself was static, but the weak alias provided an externally visible reference and thus prevented the dead code from being omitted from the output. so this change actually reduces bloat in mandatory static-linked code.
* remove lazy ssp initializationTimo Teräs2014-03-252-15/+5
| | | | | | | | now that thread pointer is initialized always, ssp canary initialization can be done unconditionally. this simplifies the ldso as it does not try to detect ssp usage, and the init function itself as it is always called exactly once. this also merges ssp init path for shared and static linking.
* always initialize thread pointer at program startRich Felker2014-03-242-13/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is the first step in an overhaul aimed at greatly simplifying and optimizing everything dealing with thread-local state. previously, the thread pointer was initialized lazily on first access, or at program startup if stack protector was in use, or at certain random places where inconsistent state could be reached if it were not initialized early. while believed to be fully correct, the logic was fragile and non-obvious. in the first phase of the thread pointer overhaul, support is retained (and in some cases improved) for systems/situation where loading the thread pointer fails, e.g. old kernels. some notes on specific changes: - the confusing use of libc.main_thread as an indicator that the thread pointer is initialized is eliminated in favor of an explicit has_thread_pointer predicate. - sigaction no longer needs to ensure that the thread pointer is initialized before installing a signal handler (this was needed to prevent a situation where the signal handler caused the thread pointer to be initialized and the subsequent sigreturn cleared it again) but it still needs to ensure that implementation-internal thread-related signals are not blocked. - pthread tsd initialization for the main thread is deferred in a new manner to minimize bloat in the static-linked __init_tp code. - pthread_setcancelstate no longer needs special handling for the situation before the thread pointer is initialized. it simply fails on systems that cannot support a thread pointer, which are non-conforming anyway. - pthread_cleanup_push/pop now check for missing thread pointer and nop themselves out in this case, so stdio no longer needs to avoid the cancellable path when the thread pointer is not available. a number of cases remain where certain interfaces may crash if the system does not support a thread pointer. at this point, these should be limited to pthread interfaces, and the number of such cases should be fewer than before.
* reduce static linking overhead from TLS support by inlining mmap syscallRich Felker2014-03-231-1/+9
| | | | | | | | | | the external mmap function is heavy because it has to handle error reporting that the kernel cannot do, and has to do some locking for arcane race-condition-avoidance purposes. for allocating initial TLS, we do not need any of that; the raw syscall suffices. on i386, this change shaves off 13% of the size of .text for the empty program.
* include cleanups: remove unused headers and add feature test macrosSzabolcs Nagy2013-12-125-6/+2
|
* remove errno setting from setenv, malloc sets it correctly on oomSzabolcs Nagy2013-10-071-1/+0
|
* fix failure to check malloc result in setenvRich Felker2013-10-041-9/+9
|
* support configurable page size on mips, powerpc and microblazeSzabolcs Nagy2013-09-151-0/+1
| | | | | | | | | | | | | | | | 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.
* add system for resetting TLS to initial valuesRich Felker2013-08-032-14/+40
| | | | | | | | | | | | | | | this is needed for reused threads in the SIGEV_THREAD timer notification system, and could be reused elsewhere in the future if needed, though it should be refactored for such use. for static linking, __init_tls.c is simply modified to export the TLS info in a structure with external linkage, rather than using statics. this perhaps makes the code more clear, since the statics were poorly named for statics. the new __reset_tls.c is only linked if it is used. for dynamic linking, the code is in dynlink.c. sharing code with __copy_tls is not practical since __reset_tls must also re-zero thread-local bss.
* remove __libc_csu_* cruftRich Felker2013-07-212-10/+0
| | | | | | | these functions were mistakenly assumed to be needed to match glibc ABI, but glibc has them as part of the non-shared part of libc that's always statically linked into the main program. moreover, the only place they are referenced from is glibc's crt1.o.
* add support for init/fini array in main program, and greatly simplifyRich Felker2013-07-211-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | modern (4.7.x and later) gcc uses init/fini arrays, rather than the legacy _init/_fini function pasting and crtbegin/crtend ctors/dtors system, on most or all archs. some archs had already switched a long time ago. without following this change, global ctors/dtors will cease to work under musl when building with new gcc versions. the most surprising part of this patch is that it actually reduces the size of the init code, for both static and shared libc. this is achieved by (1) unifying the handling main program and shared libraries in the dynamic linker, and (2) eliminating the glibc-inspired rube goldberg machine for passing around init and fini function pointers. to clarify, some background: the function signature for __libc_start_main was based on glibc, as part of the original goal of being able to run some glibc-linked binaries. it worked by having the crt1 code, which is linked into every application, static or dynamic, obtain and pass pointers to the init and fini functions, which __libc_start_main is then responsible for using and recording for later use, as necessary. however, in neither the static-linked nor dynamic-linked case do we actually need crt1.o's help. with dynamic linking, all the pointers are available in the _DYNAMIC block. with static linking, it's safe to simply access the _init/_fini and __init_array_start, etc. symbols directly. obviously changing the __libc_start_main function signature in an incompatible way would break both old musl-linked programs and glibc-linked programs, so let's not do that. instead, the function can just ignore the information it doesn't need. new archs need not even provide the useless args in their versions of crt1.o. existing archs should continue to provide it as long as there is an interest in having newly-linked applications be able to run on old versions of musl; at some point in the future, this support can be removed.
* fix omission of dtv setup in static linked programs on TLS variant I archsRich Felker2013-07-131-1/+1
| | | | | | | | | apparently this was never noticed before because the linker normally optimizes dynamic TLS models to non-dynamic ones when static linking, thus eliminating the calls to __tls_get_addr which crash when the dtv is missing. however, some libsupc++ code on ARM was calling __tls_get_addr when static linked and crashing. the reason is unclear to me, but with this issue fixed it should work now anyway.
* add support for program_invocation[_short]_nameRich Felker2013-04-061-2/+8
| | | | | | | | | | this is a bit ugly, and the motivation for supporting it is questionable. however the main factors were: 1. it will be useful to have this for certain internal purposes anyway -- things like syslog. 2. applications can just save argv[0] in main, but it's hard to fix non-portable library code that's depending on being able to get the invocation name without the main application's help.
* remove unused #undef environ now that libc.h no longer #defines itRich Felker2013-02-171-1/+0
|
* fix reference to libc struct in static tls init codeRich Felker2012-12-251-1/+1
| | | | | | | libc is the macro, __libc is the internal symbol, but under some configurations on old/broken compilers, the symbol might not actually exist and the libc macro might instead use __libc_loc() to obtain access to the object.
* fix ordering of shared library ctors with respect to libc initRich Felker2012-11-301-0/+5
| | | | | | | | | | | | | | | previously, shared library constructors were being called before important internal things like the environment (extern char **environ) and hwcap flags (needed for sjlj to work right with float on arm) were initialized in __libc_start_main. rather than trying to have to dynamic linker make sure this stuff all gets initialized right, I've opted to just defer calling shared library constructors until after the main program's entry point is reached. this also fixes the order of ctors to be the exact reverse of dtors, which is a desirable property and possibly even mandated by some languages. the main practical effect of this change is that shared libraries calling getenv from ctors will no longer fail.
* clean up sloppy nested inclusion from pthread_impl.hRich Felker2012-11-081-0/+2
| | | | | | | | | | | | | | this mirrors the stdio_impl.h cleanup. one header which is not strictly needed, errno.h, is left in pthread_impl.h, because since pthread functions return their error codes rather than using errno, nearly every single pthread function needs the errno constants. in a few places, rather than bringing in string.h to use memset, the memset was replaced by direct assignment. this seems to generate much better code anyway, and makes many functions which were previously non-leaf functions into leaf functions (possibly eliminating a great deal of bloat on some platforms where non-leaf functions require ugly prologue and/or epilogue).
* fix unused variable warningsRich Felker2012-11-012-2/+1
|
* as an extension, have putenv("VAR") behave as unsetenv("VAR")Rich Felker2012-10-211-5/+5
| | | | | | the behavior of putenv is left undefined if the argument does not contain an equal sign, but traditional implementations behave this way and gnulib replaces putenv if it doesn't do this.
* fix crashes in static-linked multithreaded programs without TLSRich Felker2012-10-191-0/+2
|
* add support for TLS variant I, presently needed for arm and mipsRich Felker2012-10-151-1/+8
| | | | | | | | | | | | | | | | | | | | | | despite documentation that makes it sound a lot different, the only ABI-constraint difference between TLS variants II and I seems to be that variant II stores the initial TLS segment immediately below the thread pointer (i.e. the thread pointer points to the end of it) and variant I stores the initial TLS segment above the thread pointer, requiring the thread descriptor to be stored below. the actual value stored in the thread pointer register also tends to have per-arch random offsets applied to it for silly micro-optimization purposes. with these changes applied, TLS should be basically working on all supported archs except microblaze. I'm still working on getting the necessary information and a working toolchain that can build TLS binaries for microblaze, but in theory, static-linked programs with TLS and dynamic-linked programs where only the main executable uses TLS should already work on microblaze. alignment constraints have not yet been heavily tested, so it's possible that this code does not always align TLS segments correctly on archs that need TLS variant I.
* i386 vsyscall support (vdso-provided sysenter/syscall instruction based)Rich Felker2012-10-111-0/+3
| | | | | | this doubles the performance of the fastest syscalls on the atom I tested it on; improvement is reportedly much more dramatic on worst-case cpus. cannot be used for cancellable syscalls.
* ensure that buffer for decoding auxv at startup is initially zeroRich Felker2012-10-081-1/+1
|
* clean up and refactor program initializationRich Felker2012-10-074-31/+30
| | | | | | | | | | | | | | | the code in __libc_start_main is now responsible for parsing auxv, rather than duplicating the parsing all over the place. this should shave off a few cycles and some code size. __init_libc is left as an external-linkage function despite the fact that it could be static, to prevent it from being inlined and permanently wasting stack space when main is called. a few other minor changes are included, like eliminating per-thread ssp canaries (they were likely broken when combined with certain dlopen usages, and completely unnecessary) and some other unnecessary checks. since this code gets linked into every program, it should be as small and simple as possible.
* fix buggy TLS size/alignment computations in static-linked TLSRich Felker2012-10-061-5/+22
|
* support for TLS in dynamic-loaded (dlopen) modulesRich Felker2012-10-051-2/+2
| | | | | | | | | | | | | | | | | | | | | 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.
* partial TLS support for dynamic-linked programsRich Felker2012-10-041-5/+5
| | | | | only TLS in the main program is supported so far; TLS defined in shared libraries will not work yet.
* TLS (GNU/C11 thread-local storage) support for static-linked programsRich Felker2012-10-042-0/+73
| | | | | | | | | | | | | the design for TLS in dynamic-linked programs is mostly complete too, but I have not yet implemented it. cost is nonzero but still low for programs which do not use TLS and/or do not use threads (a few hundred bytes of new code, plus dependency on memcpy). i believe it can be made smaller at some point by merging __init_tls and __init_security into __libc_start_main and avoiding duplicate auxv-parsing code. at the same time, I've also slightly changed the logic pthread_create uses to allocate guard pages to ensure that guard pages are not counted towards commit charge.
* ensure canary is setup if stack-prot libs are dlopen'd into non-ssp appRich Felker2012-08-251-1/+2
| | | | | | previously, this usage could lead to a crash if the thread pointer was still uninitialized, and otherwise would just cause the canary to be zero (less secure).
* save AT_HWCAP from auxv for subsequent use in machine-specific codeRich Felker2012-07-271-0/+1
| | | | | | | 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.
* direct syscall to open in __init_security needs O_LARGEFILERich Felker2012-06-141-1/+1
| | | | | it probably does not matter for /dev/null, but this should be done consistently anyway.
* fix missing static (namespace clash)Rich Felker2012-05-101-1/+1
|
* overhaul SSP support to use a real canaryRich Felker2012-05-033-8/+17
| | | | | | | | | | | | | pthread structure has been adjusted to match the glibc/GCC abi for where the canary is stored on i386 and x86_64. it will need variants for other archs to provide the added security of the canary's entropy, but even without that it still works as well as the old "minimal" ssp support. eventually such changes will be made anyway, since they are also needed for GCC/C11 thread-local storage support (not yet implemented). care is taken not to attempt initializing the thread pointer unless the program actually uses SSP (by reference to __stack_chk_fail).
* make stack protector work with gcc configured for non-tls canaryRich Felker2012-04-301-0/+2
|
* first attempt at enabling stack protector supportRich Felker2012-04-242-0/+21
| | | | | | | | the code is written to pre-init the thread pointer in static linked programs that pull in __stack_chk_fail or dynamic-linked programs that lookup the symbol. no explicit canary is set; the canary will be whatever happens to be in the thread structure at the offset gcc hard-coded. this can be improved later.
* bring back ___environ symbol (3 underscores)Rich Felker2011-08-231-0/+1
| | | | | | its existence doesn't hurt anything, and dynamic-linked binaries using previous versions of musl were wrongly binding to it instead of __environ.
* security hardening: ensure suid programs have valid stdin/out/errRich Felker2011-08-233-13/+38
| | | | | | | | | | | 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!)
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-04 15:11:56 +0000