| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this facilitates building software that assumes a large default stack
size without any patching to call pthread_setattr_default_np or
pthread_attr_setstacksize at each thread creation site, using just
LDFLAGS.
normally the PT_GNU_STACK header is used only to reflect whether
executable stack is desired, but with GNU ld at least, passing
-Wl,-z,stack-size=N will set a size on the program header. with this
patch, that size will be incorporated into the default stack size
(subject to increase-only rule and DEFAULT_STACK_MAX limit).
both static and dynamic linking honor the program header. for dynamic
linking, all libraries loaded at program start, including preloaded
ones, are considered. dlopened libraries are not considered, for
several reasons. extra logic would be needed to defer processing until
the load of the new library is commited, synchronization woud be
needed since other threads may be running concurrently, and the
effectiveness woud be limited since the larger size would not apply to
threads that already existed at the time of dlopen. programs that will
dlopen code expecting a large stack need to declare the requirement
themselves, or pthread_setattr_default_np can be used.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
stack size default is increased from 80k to 128k. this coincides with
Linux's hard-coded default stack for the main thread (128k is
initially committed; growth beyond that up to ulimit is contingent on
additional allocation succeeding) and GNU ld's default PT_GNU_STACK
size for FDPIC, at least on sh.
guard size default is increased from 4k to 8k to reduce the risk of
guard page jumping on overflow, since use of just over 4k of stack is
common (PATH_MAX buffers, etc.).
|
| |
|
|
|
|
|
|
|
|
| |
limit to 8MB/1MB, repectively. since the defaults cannot be reduced
once increased, excessively large settings would lead to an
unrecoverably broken state. this change is in preparation to allow
defaults to be increased via program headers at the linker level.
creation of threads that really need larger sizes needs to be done
with an explicit attribute.
|
| |
|
|
| |
these are now declared in pthread_impl.h.
|
| |
|
|
| |
access to defaults should be protected against concurrent changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
per POSIX, deletion of a key for which some threads still have values
stored is permitted, and newly created keys must initially hold the
null value in all threads. these properties were not met by our
implementation; if a key was deleted with values left and a new key
was created in the same slot, the old values were still visible.
moreover, due to lack of any synchronization in pthread_key_delete,
there was a TOCTOU race whereby a concurrent pthread_exit could
attempt to call a null destructor pointer for the newly orphaned
value.
this commit introduces a solution based on __synccall, stopping the
world to zero out the values for deleted keys, but only does so lazily
when all key slots have been exhausted. pthread_key_delete is split
off into a separate translation unit so that static-linked programs
which only create keys but never delete them will not pull in the
__synccall machinery.
a global rwlock is added to synchronize creation and deletion of keys
with dtor execution. since the dtor execution loop now has to release
and retake the lock around its call to each dtor, checks are made not
to call the nodtor dummy function for keys which lack a dtor.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The condition occurs when
- thread #1 is holding the lock
- thread #2 is waiting for it on __futexwait
- thread #1 is about to release the lock and performs a_swap
- thread #3 enters the __lockfile function and manages to grab the lock
before thread #1 calls __wake, resetting the MAYBE_WAITERS flag
- thread #1 calls __wake
- thread #2 wakes up but goes again to __futexwait as the lock is
held by thread #3
- thread #3 releases the lock but does not call __wake as the
MAYBE_WAITERS flag is not set
This condition results in thread #2 not being woken up. This patch fixes
the problem by making the woken up thread ensure that the flag is
properly set before going to sleep again.
Mainainer's note: This fixes a regression introduced in commit
c21f750727515602a9e84f2a190ee8a0a2aeb2a1.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit b114190b29417fff6f701eea3a3b3b6030338280 introduced spurious
realloc of the output buffer in cases where the result would exactly
fit in the caller-provided buffer. this is contrary to a strict
reading of the spec, which only allows realloc when the provided
buffer is "of insufficient size".
revert the adjustment of the realloc threshold, and instead push the
byte read by getc_unlocked (for which the adjustment was made) back
into the stdio buffer if it does not fit in the output buffer, to be
read in the next loop iteration.
in order not to leave a pushed-back byte in the stdio buffer if
realloc fails (which would violate the invariant that logical FILE
position and underlying open file description offset match for
unbuffered FILEs), the OOM code path must be changed. it would suffice
move just one byte in this case, but from a QoI perspective, in the
event of ENOMEM the entire output buffer (up to the allocated length
reported via *n) should contain bytes read from the FILE stream.
otherwise the caller has no way to distinguish trunated data from
uninitialized buffer space.
the SIZE_MAX/2 check is removed since the sum of disjoint object sizes
is assumed not to be able to overflow, leaving just one OOM code path.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
morally, for null pointers a and b, a-b, a<b, and a>b should all be
defined as 0; however, C does not define any of them.
the stdio implementation makes heavy use of such pointer comparison
and subtraction for buffer logic, and also uses null pos/base/end
pointers to indicate that the FILE is not in the corresponding (read
or write) mode ready for accesses through the buffer.
all of the comparisons are fixed trivially by using != in place of the
relational operators, since the opposite relation (e.g. pos>end) is
logically impossible. the subtractions have been reviewed to check
that they are conditional the stream being in the appropriate reading-
or writing-through-buffer mode, with checks added where needed.
in fgets and getdelim, the checks added should improve performance for
unbuffered streams by avoiding a do-nothing call to memchr, and should
be negligible for buffered streams.
|
| |
|
|
|
| |
if EINVAL or ENOMEM happened before the first getc_unlocked, it was
possible that the stream orientation had not yet been set.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on some archs, linux support for futex operations (including
robust_list processing) that depend on kernelspace CAS is conditional
on a runtime check. as of linux 4.18, this check fails unconditionally
on nommu archs that perform it, and spurious failure on powerpc64 was
observed but not explained. it's also possible that futex support is
omitted entirely, or that the kernel is older than 2.6.17. for most
futex ops, ENOSYS does not yield hard breakage; userspace will just
spin at 100% cpu load. but for robust mutexes, correct behavior
depends on the kernel functionality.
use the get_robust_list syscall to probe for support at the first call
to pthread_mutexattr_setrobust, and block creation of robust mutexes
with a reportable error if they can't be supported.
|
| |
|
|
|
| |
do_tzset() did't always reset the DST transition rules r0 and r1. That
means the rules from older TZ settings could leak into newer ones.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in order to produce FILE objects to pass to the intscan/floatscan
backends without any (prohibitively costly) extra buffering layer, the
strto* functions set the FILE's rend (read end) buffer pointer to an
invalid value at the end of the address space, or SIZE_MAX/2 past the
beginning of the string. this led to undefined behavior comparing and
subtracting the end pointer with the buffer position pointer (rpos).
the comparison issue is easily eliminated by using != instead of <.
however the subtractions require nontrivial changes:
previously, f->shcnt stored the count that would have been read if
consuming the whole buffer, which required an end pointer for the
buffer. the purpose for this was that it allowed reading it and adding
rpos-rend at any time to get the actual count so far, and required no
adjustment at the time of __shgetc (actual function call) since the
call would only happen when reaching the end of the buffer.
to get rid of the dependency on rend, instead offset shcnt by buf-rpos
(start of buffer) at the time of last __shlim/__shgetc call. this
makes for slightly more work in __shgetc the function, but for the
inline macro it's still just as easy to compute the current count.
since the scan helper interfaces used here are a big hack, comments
are added to document their contracts and what's going on with their
implementations.
|
| |
|
|
|
|
|
|
|
| |
POSIX allows ttyname(_r) and isatty to return EBADF if passed file
descriptor is invalid.
maintainer's note: these are optional ("may fail") errors, but it's
non-conforming for ttyname_r to return ENOTTY when it failed for a
different reason.
|
| |
|
|
|
|
|
|
|
|
|
| |
this significantly improves codegen in functions that need to access
errno but otherwise have no need for a GOT pointer.
we could probably improve it much more by including an inline version
of the &errno accessor function, but that depends on having the
definitions of struct __pthread and __pthread_self(), which at present
would expose a lot more than is appropriate. moving them to a small
tls.h later might make this more reasonable.
|
| |
|
|
|
|
| |
commit 5ce3737931bb411a8d167356d4d0287b53b0cbdc removed the inclusion
of libc.h from this file as spurious, but it's needed to get PAGE_SIZE
on archs where PAGE_SIZE is not a constant defined by limits.h.
|
| |
|
|
|
|
|
|
|
|
|
| |
there is no good reason to wait to find and process the plural rules
for a translated message file until a gettext form requesting plural
rule processing is used. it just imposes additional synchronization,
here in the form of clunky use of atomics.
it looks like there may also have been a race condition where nplurals
could be seen without plural_rule being seen, possibly leading to null
pointer dereference. if so, this commit fixes it.
|
| |
|
|
|
|
|
|
|
| |
as originally published, the C99 syntax only allowed static index
parameter declarators when a gratuitous parameter name was included.
gcc 3, which some projects use for bootstrapping, is a supported C99
compiler, but does not have the fix to the standard incorporated, so
edit the affected declaration to conform to the earlier buggy C99
syntax.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
since commit dc2f368e565c37728b0d620380b849c3a1ddd78f this has been
disabled by default, but was left available in case users unhappy with
the resulting size or performance regressions wanted to try to make it
work. now that we make widespread use of hidden visibility for
internal interfaces, this no longer makes sense. if any costly calls
remain they can be fixed with hidden aliases.
|
| |
|
|
|
|
|
|
|
| |
this further reduces the number of source files which need to include
libc.h and thereby be potentially exposed to libc global state and
internals.
this will also facilitate further improvements like adding an inline
fast-path, if we want to do so later.
|
| |
|
|
|
|
|
|
| |
pthread_atfork.c does not actually include pthread_impl.h and has no
reason to, so it wasn't getting the declaration. move it to libc.h
which is already included by both fork.c and pthread_atfork.c. this
makes more sense anyway since the function has little to do with
pthreads anyway aside from the name.
|
| |
|
|
|
|
| |
the LFS64 macro was not self-documenting and barely saved any
characters. simply use weak_alias directly so that it's clear what's
being done, and doesn't depend on a header to provide a strange macro.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libc.h was intended to be a header for access to global libc state and
related interfaces, but ended up included all over the place because
it was the way to get the weak_alias macro. most of the inclusions
removed here are places where weak_alias was needed. a few were
recently introduced for hidden. some go all the way back to when
libc.h defined CANCELPT_BEGIN and _END, and all (wrongly implemented)
cancellation points had to include it.
remaining spurious users are mostly callers of the LOCK/UNLOCK macros
and files that use the LFS64 macro to define the awful *64 aliases.
in a few places, new inclusion of libc.h is added because several
internal headers no longer implicitly include libc.h.
declarations for __lockfile and __unlockfile are moved from libc.h to
stdio_impl.h so that the latter does not need libc.h. putting them in
libc.h made no sense at all, since the macros in stdio_impl.h are
needed to use them correctly anyway.
|
| |
|
|
|
|
|
|
|
|
| |
not all prefixed symbols can be made hidden. some are part of
ABI-compat (e.g. __nl_langinfo_l) and others are ABI as a consequence
of the way copy relocations for weak aliases work in ELF shared
libraries. most, however, can be made hidden.
with this commit, there should be no remaining unintentionally visible
symbols exported from libc.so.
|
| |
|
|
|
|
|
| |
this was added so that posix_spawn and possibly other functionality
could be implemented in terms of vfork, but that turned out to be
unsafe. any such usage needs __clone with proper handling of stack
lifetime.
|
| | |
|
| |
|
|
|
| |
this is perhaps not the ideal place, but no better alternatives stand
out.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
the direct syscall or various thin and mostly-inline wrappers around
it are used instead internally. at some point a public futex function
should be added, but it's not yet clear what the signature should be,
and in the mean time this file is not useful.
|
| |
|
|
|
|
|
|
|
| |
this is a special case that does not need a declaration, because it's
not even a libc-internal interface between translation units. instead
it's a poor hack around compilers' inability to shrink-wrap critical
code paths. after vis.h was disabled, it became more of a
pessimization on many archs due to the extra layer of machinery to
support a call through the PLT, but now it should be efficient again.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
the __-prefixed filename does not make sense when the only purpose of
this file is implementing a public function that's not used as a
backend for implementing the standard dirent functions.
|
| | |
|
| |
|
|
| |
these were overlooked for various reasons in earlier stages.
|
| | |
|
| |
|
|
|
|
|
| |
these were overlooked in the declarations overhaul work because they
are not properly declared, and the current framework even allows their
declared types to vary by arch. at some point this should be cleaned
up, but I'm not sure what the right way would be.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
this makes significant differences to codegen on archs with an
expensive PLT-calling ABI; on i386 and gcc 7.3 for example, the sin
and sinf functions no longer touch call-saved registers or the stack
except for pushing outgoing arguments. performance is likely improved
too, but no measurements were taken.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commits leading up to this one have moved the vast majority of
libc-internal interface declarations to appropriate internal headers,
allowing them to be type-checked and setting the stage to limit their
visibility. the ones that have not yet been moved are mostly
namespace-protected aliases for standard/public interfaces, which
exist to facilitate implementing plain C functions in terms of POSIX
functionality, or C or POSIX functionality in terms of extensions that
are not standardized. some don't quite fit this description, but are
"internally public" interfacs between subsystems of libc.
rather than create a number of newly-named headers to declare these
functions, and having to add explicit include directives for them to
every source file where they're needed, I have introduced a method of
wrapping the corresponding public headers.
parallel to the public headers in $(srcdir)/include, we now have
wrappers in $(srcdir)/src/include that come earlier in the include
path order. they include the public header they're wrapping, then add
declarations for namespace-protected versions of the same interfaces
and any "internally public" interfaces for the subsystem they
correspond to.
along these lines, the wrapper for features.h is now responsible for
the definition of the hidden, weak, and weak_alias macros. this means
source files will no longer need to include any special headers to
access these features.
over time, it is my expectation that the scope of what is "internally
public" will expand, reducing the number of source files which need to
include *_impl.h and related headers down to those which are actually
implementing the corresponding subsystems, not just using them.
|
| |
|
|
|
|
| |
it's not ideal, but the function is essentially an extended stdio
function specialized to getopt's needs. the only reason it exists is
avoiding pulling printf code into every program using getopt.
|
| |
|
|
|
|
| |
the public flockfile interface is significantly heavier because it has
to handle the possibility of caller returning or thread exiting while
holding the lock.
|
| | |
|
| | |
|
