commit 378f8cb522 added these functions
(as stubs) but left them without declarations. this broke some
autoconf based software that detected linkability of the symbols but
didn't check for a declaration.
when the size argument was zero but nmemb was nonzero, these functions
were returning nmemb, despite no data having been written.
conceptually this is not wrong, but the standard requires a return
value of zero in this case.
as specified, the int argument providing the character to write is
converted to type unsigned char. for the actual write to buffer,
conversion happened implicitly via the assignment operator; however,
the logic to check whether the argument was a newline used the
original int value. thus usage such as putchar('\n'+0x100) failed to
produce a flush.
when a write error occurred while flushing output due to a newline,
fwrite falsely reported all bytes up to and including the newline as
successfully written. in general, due to buffering such "spurious
success" returns are acceptable for stdio; however for line-buffered
mode it was subtly wrong. errors were still visible via ferror() or as
a short-write return if there was more data past the newline that
should have been written, but since the contract for line-buffered
mode is that everything up through the newline be written out
immediately, a discrepency was observable in the actual file contents.
the workaround was for a bug that botched .gpword references to local
labels, applying a nonsensical random offset of -0x4000 to them.
this reverses commit 5e396fb996 and a
removes a similar hack that was added to syscall_cp.s in the later
commit 756c8af858. it turns out one
additional instance of the same idiom, the GETFUNCSYM macro in
arch/mips/reloc.h, was still affected by the assembler bug and does
not admit an easy workaround without making assumptions about how the
macro is used. the previous workarounds made static linking work but
left the early-stage dynamic linker broken and thus had limited
usefulness.
instead, affected users (using binutils versions older than 2.20) will
need to fix the bug on the binutils side; the trivial patch is commit
453f5985b13e35161984bf1bf657bbab11515aa4 in the binutils-gdb
repository.
the old __cp_cancel code path loaded the address of __cancel from the
GOT using the $gp register, which happened to be set to point to the
correct GOT by the calling C function, but there is no ABI requirement
that this happen. instead, go the roundabout way and compute the
address of __cancel via pc-relative and gp-relative addressing
starting with a fake return address generated by a bal instruction,
which is the same trick crt1 uses to bootstrap.
add aarch64 and or1k archs, upgrade sh from experimental, and note
that sh now supports the FDPIC ABI.
the old advice on compiler versions was outdated and more specific
than made sense. presence of compiler bugs varies a lot by arch, so
it's hard to make any good recommendations beyond "recent". if we want
to document specific known-good/bad compiler versions, a much larger
section in the documentation than what's appropriate for the INSTALL
file would be needed.
the linux man page specifies malloc_usable_size(0) to return 0 and
this is the semantics other implementations follow (jemalloc).
reported by Alexander Monakov.
10k elements stack is increased to 1000k, otherwise tnfa creation fails
for reasonable sized patterns: a single literal char can add 7 elements
to this stack, so regcomp of an 1500 char long pattern (with only litral
chars) fails with REG_ESPACE. (the new limit allows about < 150k chars,
this arbitrary limit allows most command line regex usage.)
ideally there would be no upper bound: regcomp dynamically reallocates
this buffer, every reallocation checks for allocation failure and at
the end this stack is freed so there is no reason for special bound.
however that may have unwanted effect on regcomp and regexec runtime
so this is a conservative change.
"Q" input constraint was used for the written object, instead of "=Q"
output constraint. this should not cause problems because "memory"
is on the clobber list, but "=Q" better documents the intent and more
consistent with the actual asm code.
this changes the generated code, because different registers are used,
but other than the register names nothing should change.
previous work overhauling the dynamic linker made it so that linking
libc with -Bsymbolic-functions was no longer mandatory, but the
configure logic that forced --disable-shared when ld failed to accept
the option was left in place.
this commit removes the hard-coded -Bsymbolic-functions from the
Makefile and changes the configure test to one that simply adds it to
the auto-detected LDFLAGS on success.
The standard does not define semantics for \| in BRE, but some code
depends on it meaning alternation. Empty alternative expression is
allowed to be consistent with ERE.
Based on a patch by Rob Landley.
Previously repetitions were accepted after empty expressions like
in (*|?)|{2}, but in BRE the handling of * and \{\} were not
consistent: they were accepted as literals in some cases and
repetitions in others.
It is better to treat repetitions after an empty expression as an
error (this is allowed by the standard, and glibc mostly does the
same). This is hard to do consistently with the current logic so
the new rule is:
Reject repetitions after empty expressions, except after assertions
^*, $? and empty groups ()+ and never treat them as literals.
Empty alternation (|a) is undefined by the standard, but it can be
useful so that should be accepted.
this file's .data section was not aligned, and just happened to get
the correct alignment with past builds. it's likely that the move of
atomic.s from arch/arm/src to src/thread/arm caused the change in
alignment, which broke the atomic and thread-pointer access fragments
on actual armv5 hardware.
commit d56460c939 introduced this bug by
setting up the tls module chain incorrectly when the main app has tls.
the singly-linked list head pointer was setup correctly, but the tail
pointer was not, so the first attempt to append to the list (for a
shared library with tls) would treat the list as empty and effectively
removed the main app from the list. this left all tls module id
numbers off-by-one.
this bug did not appear in any released versions.
search is only performed if the search or domain keyword is used in
resolv.conf and the queried name has fewer than ndots dots. there is
no default domain and names with >=ndots dots are never subjected to
search; failure in the root scope is final.
the (non-POSIX) res_search API presently does not honor search. this
may be added at some point in the future if needed.
resolv.conf is now parsed twice, at two different layers of the code
involved. this will be fixed in a subsequent patch.
rcode of 3 (NxDomain) was treated as a hard EAI_NONAME failure, but it
should instead return 0 (no results) so the caller can continue
searching. this will be important for adding search domain support.
the top-level caller will automatically return EAI_NONAME if there are
zero results at the end.
also, the case where rcode is 0 (success) but there are no results was
not handled. this happens when the domain exists but there are no A or
AAAA records for it. in this case a hard EAI_NONAME should be imposed
to inhibit further search, since the name was defined and just does
not have any address associated with it. previously a misleading hard
failure of EAI_FAIL was reported.
this change is made in preparation for adding search domains, for
which higher-level code will need to parse resolv.conf. simply parsing
it twice for each lookup would be one reasonable option, but the
existing parser code was buggy anyway, which suggested to me that it's
a bad idea to have two variants of this code in two different places.
the old code in res_msend potentially misinterpreted overly long lines
in resolv.conf, and stopped parsing after it found 3 nameservers, even
if there were relevant options left to be parsed later in the file.
all bits headers that were identical for a number of 'clean' archs are
moved to the new arch/generic tree. in addition, a few headers that
differed only cosmetically from the new generic version are removed.
additional deduplication may be possible in mman.h and in several
headers (limits.h, posix.h, stdint.h) that mostly depend on whether
the arch is 32- or 64-bit, but they are left alone for now because
greater gains are likely possible with more invasive changes to header
logic, which is beyond the scope of this commit.
this sets the stage for the first phase of the bits deduplication.
bits headers which are identical for "most" archs will be moved to
arch/generic/bits.
vdso support is available on mips starting with kernel 4.4, see kernel
commit a7f4df4e21 "MIPS: VDSO: Add implementations of gettimeofday()
and clock_gettime()" for details.
In Linux kernel 4.4.0 the mips code returns -ENOSYS in case it can not
handle the vdso call and assumes the libc will call the original
syscall in this case. Handle this case in musl. Currently Linux kernel
4.4.0 handles the following types: CLOCK_REALTIME_COARSE,
CLOCK_MONOTONIC_COARSE, CLOCK_REALTIME and CLOCK_MONOTONIC.
these changes are motivated by a functionally similar patch by Hauke
Mehrtens to address the needs of the new mips vdso clock_gettime,
which wrongly fails with ENOSYS rather than falling back to making a
syscall for clock ids it cannot handle from userspace. in the process
of preparing to handle that case, it was noticed that the old
clock_gettime use of the vdso was actually wrong with respect to error
handling -- the tail call to the vdso function failed to set errno and
instead returned an error code.
since tail calls to vdso are no longer possible and since the plain
syscall code is now needed as a fallback path anyway, it does not make
sense to use a function pointer to call the plain syscall code path.
instead, it's inlined at the end of the main clock_gettime function.
the new code also avoids the need to test for initialization of the
vdso function pointer by statically initializing it to a self-init
function, and eliminates redundant loads from the volatile pointer
object.
finally, the use of a_cas_p on an object of type other than void *,
which is not permitted aliasing, is replaced by using an object with
the correct type and casting the value.
si_errno and si_code are swapped in mips siginfo_t compared to other
archs and some si_code values are different. This fix is required
for POSIX timers to work.
based on patch by Dmitry Ivanov.
only have code above the bits/signal.h include that is necessary.
(some types are used for the ucontext struct and mips has to
override a few macro definitions)
this way mips bits/signal.h will be able to affect siginfo_t.
they lock faulted pages into memory (useful when a small part of a
large mapped file needs efficient access), new in linux v4.4, commit
b0f205c2a3082dd9081f9a94e50658c5fa906ff1
MLOCK_* is not in the POSIX reserved namespace for sys/mman.h
this is mlock with a flags argument, new in linux commit
a8ca5d0ecbdde5cc3d7accacbd69968b0c98764e
as usual microblaze and sh don't have allocated syscall number yet.
allows a ptracer process to disable/enable seccomp filters of the
traced process, useful for checkpoint/restore, new in v4.3 commit
13c4a90119d28cfcb6b5bdd820c233b86c2b0237
new in linux v4.3 added for aarch64, arm, i386, mips, or1k, powerpc,
x32 and x86_64.
membarrier is a system wide memory barrier, moves most of the
synchronization cost to one side, new in kernel commit
5b25b13ab08f616efd566347d809b4ece54570d1
userfaultfd is useful for qemu and is new in kernel commit
8d2afd96c20316d112e04d935d9e09150e988397
switch_endian is powerpc only for switching endianness, new in commit
529d235a0e190ded1d21ccc80a73e625ebcad09b
new in linux v4.3 commit 9dea5dc921b5f4045a18c63eb92e84dc274d17eb
direct calls instead of socketcall allow better seccomp filtering.
musl continues to use socketcalls internally on i386. (older kernels
would need a fallback mechanism if the direct calls were used.)
only use SYS_socketcall if SYSCALL_USE_SOCKETCALL is defined
internally, otherwise use direct syscalls.
this commit does not change the current behaviour, it is
preparation for adding direct syscall numbers for i386.
these were not covered by the parent-level rules with the new build
system. in the old build system, the equivalent files were often in
arch/$(ARCH)/src and likewise lacked the suppression. this could lead
to early crashing (before thread pointer init) when libc itself was
built with stack protector enabled.
now that .lo and .o files differ only by whether -fPIC is passed (and
no longer at the source level based on the SHARED macro), it's
possible to use the same object files for both static and shared libc
when the compiler would produce PIC for the static files anyway. this
happens if the user has included -fPIC in their CFLAGS or if the
compiler has been configured to produce PIE by default.
we use the .lo files for both, and still append -fPIC to the CFLAGS,
rather than using the .o files so that libc.so does not break
catastrophically if the user later removes -fPIC from CFLAGS in
config.mak or on the make command line. this also ensures that we get
full -fPIC in case -fpic, -fPIE, or some other lesser-PIC option was
passed in CFLAGS.
this eliminates the last need for the SHARED macro to control how
files in the src tree are compiled. the same code is used for both
libc.a and libc.so, with additional code for the dynamic linker (from
the new ldso tree) being added to libc.so but not libc.a. separate .o
and .lo object files still exist for the src tree, but the only
difference is that the .lo files are built as PIC.
in the future, if/when we add dlopen support for static-linked
programs, much of the code in dynlink.c may be moved back into the src
tree, but properly factored into separate source files. in that case,
the code in the ldso tree will be reduced to just the dynamic linker
entry point, self-relocation, and loading of libraries needed by the
main application.
Rich Felker
Szabolcs Nagy
Felix Fietkau
Kylie McClain
Hauke Mehrtens