| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
a null pointer is valid here and indicates that the current time
should be used. based on patch by Felix Janda, simplified.
|
|
i386, x86_64, x32, and powerpc all use TLS for stack protector canary
values in the default stack protector ABI, but the location only
matched the ABI on i386 and x86_64. on x32, the expected location for
the canary contained the tid, thus producing spurious mismatches
(resulting in process termination) upon fork. on powerpc, the expected
location contained the stdio_locks list head, so returning from a
function after calling flockfile produced spurious mismatches. in both
cases, the random canary was not present, and a predictable value was
used instead, making the stack protector hardening much less effective
than it should be.
in the current fix, the thread structure has been expanded to have
canary fields at all three possible locations, and archs that use a
non-default location must define a macro in pthread_arch.h to choose
which location is used. for most archs (which lack TLS canary ABI) the
choice does not matter.
|
|
this is analogous to commit 2ca55a93f2a11185d72dcb69006fd2c30b5c3144
for the macros in ctype.h.
|
|
|
|
the 64-bit push reads not only the 32-bit return address but also the
first 32 signal mask bits. if any were nonzero, the return address
obtained will be invalid.
at some point storage of the return address should probably be moved
to follow the saved mask so that there's plenty room and the same code
can be used on x32 and regular x86_64, but for now I want a fix that
does not risk breaking x86_64, and this simple re-zeroing works.
|
|
the kernel does not properly clear the upper bits of the syscall
argument, so we have to do it before the syscall.
|
|
the lifetime of compound literals is the block in which they appear.
the temporary struct __timespec_kernel objects created as compound
literals no longer existed at the time their addresses were passed to
the kernel.
|
|
These macros were introduced in glibc 2.12 to follow RFC 2474 which
deprecates "IP Precedence" in favor of "Class Selector Codepoints".
|
|
These cases were incorrect in C11 as described by
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1886.htm
|
|
|
|
due to an incorrect return statement in this error case, the
previously blocked cancellation state was not restored and no result
was stored. this could lead to invalid (read) accesses in the caller
resulting in crashes or nonsensical result data in the event of memory
exhaustion.
|
|
remove __syscall declaration where it is not needed (aarch64, arm,
microblaze, or1k) and add the hidden attribute where it is (mips).
|
|
commit f3ddd173806fd5c60b3f034528ca24542aecc5b9 broke the build by
using "bx" instead of "br".
|
|
while the sh port is still experimental and subject to ABI
instability, this is not actually an application/libc boundary ABI
change. it only affects third-party APIs where jmp_buf is used in a
shared structure at the ABI boundary, because nothing anywhere near
the end of the jmp_buf object (which includes the oversized sigset_t)
is accessed by libc.
both glibc and uclibc have 15-slot jmp_buf for sh. presumably the
smaller version was used in musl because the slots for fpu status
register and thread pointer register (gbr) were incorrect and must not
be restored by longjmp, but the size should have been preserved, as
it's generally treated as a libc-agnostic ABI property for the arch,
and having extra slots free in case we ever need them for something is
useful anyway.
|
|
|
|
at least some assembler versions do not accept the register name lr.
use the name x30 instead.
|
|
previously it was using the same name as the default ABI with hard
float (floating point args and return value in registers).
the test __SH_FPU_ANY__ || __SH4__ matches what's used in the
configure script already, and seems correct under casual review
against gcc's config/sh.h, but may need tweaks. the logic for
predefined macros for sh, and what they all mean, is very complex.
eventually this should be documented in comments here.
configure already rejects "half-hard" configurations on sh where
double=float since these do not conform to Annex F and are not
suitable for musl, so these do not need to be considered here.
|
|
commit 646cb9a4a04e5ed78e2dd928bf9dc6e79202f609 switched sigsetjmp to
use the new hidden ___setjmp symbol for setjmp, but the nofpu variant
of setjmp.s was not updated to match.
|
|
versions of reloc.h that rely on endian macros much include endian.h
to ensure they are available.
|
|
both static and dynamic linked versions of the __copy_tls function
have a hidden assumption that the alignment of the beginning or end of
the memory passed is suitable for storing an array of pointers for the
dtv. pthread_create satisfies this requirement except when
libc.tls_size is misaligned, which cannot happen with dynamic linking
due to way update_tls_size computes the total size, but could happen
with static linking and odd-sized TLS.
|
|
commit dab441aea240f3b7c18a26d2ef51979ea36c301c, which made thread
pointer init mandatory for all programs, rendered this store obsolete
by removing the early-return path for static programs with no TLS.
|
|
this slightly reduces the code size cost of TLS/thread-pointer for
static linking since __init_tp can be inlined into its only caller and
removed. this is analogous to the handling of __init_libc in
__libc_start_main, where the function only has external linkage when
it needs to be called from the dynamic linker.
|
|
|
|
the implicit-operand form of fucomip is rejected by binutils 2.19 and
perhaps other versions still in use. writing both operands explicitly
fixes the issue. there is no change to the resulting output.
commit a732e80d33b4fd6f510f7cec4f5573ef5d89bc4e was the source of this
regression.
|
|
|
|
use CAS instead of swap since it's lighter for most archs, and keep
EBUSY in the lock value so that the old value obtained by CAS can be
used directly as the return value for pthread_spin_trylock.
|
|
|
|
the motivation for this change is that the extra declaration (with or
without visibility) using "struct _IO_FILE" instead of "FILE" seems to
trigger a bug in gcc 3.x where it considers the types mismatched.
however, this change also results in slightly better code and it is
valid because (1) these three objects are constant, and (2) applying
the & operator to any of them is invalid C, since they are not even
specified to be objects. thus it does not matter if the application
and libc see different addresses for them, as long as the (initial,
unchanging) value is seen the same by both.
|
|
these are used as hidden by asm files (and such use is the whole
reason they exist), but their actual definitions were not hidden.
|
|
commit f9cccfc16e58b39ee381fbdfb8688db3bb8e3555 left behind the part
in libc.c; remove it too.
|
|
part of the goal here is to eliminate use of the ATTR_LIBC_VISIBILITY
macro outside of libc.h, since it was never intended to be 'public'.
|
|
|
|
these were hacks to work around toolchains that could not properly
optimize PIC accesses based on visibility and would generate GOT
lookups even for hidden data, which broke the old dynamic linker.
since commit f3ddd173806fd5c60b3f034528ca24542aecc5b9 it no longer
matters; the dynamic linker does not assume accessibility of this data
until stage 3.
|
|
pcc does not search for -include relative to the working directory
unless -I. is used. rather than adding -I., which could be problematic
if there's extra junk in the top-level directory, switch back to the
old method (reverting commit 60ed988fd6c67b489d7cc186ecaa9db4e5c25b8c)
of using -include vis.h and relying on -I./src/internal being present
on the command line (which the Makefile guarantees). to fix the
breakage that was present in trycppif checks with the old method,
$CFLAGS_AUTO is removed from the command line passed to trycppif; this
is valid since $CFLAGS_AUTO should not contain options that alter
compiler semantics or ABI, only optimizations, warnings, etc.
|
|
when the non-stub duplocale code was added as part of the locale
framework in commit 0bc03091bb674ebb9fa6fe69e4aec1da3ac484f2, the old
code to memcpy the old locale object to the new one was left behind.
the conditional for the memcpy no longer makes sense, because the
conditions are now always-true when it's reached, and the memcpy is
wrong because it clobbers the new->messages_name pointer setup just
above.
since the messages_name and ctype_utf8 members have already been
copied, all that remains is the cat[] array. these pointers are
volatile, so using memcpy to copy them is formally wrong; use a for
loop instead.
|
|
Some build environments pass -march and -mtune as part of CC, therefore
update configure to check both CC and CFLAGS before making the decision
to fall back to generic -march and -mtune options for x86.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
|
|
the first switch already returns in the F_SETLKW code path so it need
not be handled in the second switch. moreover the code in the second
switch is wrong for the F_SETLKW command: it's not cancellable.
|
|
the leak was found by static analysis (reported by Alexander Monakov),
not tested/observed, but seems to have occured both when failing due
to O_EXCL, and in a race condition with O_CREAT but not O_EXCL where a
semaphore by the same name was created concurrently.
|
|
the allocating path which can fail is for dynamic TLS, which can only
occur at runtime, and the check for runtime was already made in the
outer conditional.
|
|
commit 637dd2d383cc1f63bf02a732f03786857b22c7bd introduced the checks
for RTLD_DEFAULT and RTLD_NEXT here, claiming they fixed a regression,
but the above conditional block clearly already covered these cases,
and removing the checks produces no difference in the generated code.
|
|
the jmp instruction requires a 64-bit register, so cast the desired PC
address up to uint64_t, going through uintptr_t to ensure that it's
zero-extended rather than possibly sign-extended.
|
|
commit de2b67f8d41e08caa56bf6540277f6561edb647f introduced a
regression by adding a -include option to CFLAGS_AUTO which did not
work without additional -I options. this broke subsequent trycppif
tests and caused x86_64 to be misdetected as x32, among other issues.
simply using the full relative pathname to vis.h rather than -I is the
cleanest way to fix the problem.
|
|
this is implemented via the build system and does not affect source
files. the idea is to use protected or hidden visibility to prevent
the compiler from pessimizing function calls within a shared (or
position-independent static) libc in the form of overhead setting up
for a call through the PLT. the ld-time symbol binding via the
-Bsymbolic-functions option already optimized out the PLT itself, but
not the code in the caller needed to support a call through the PLT.
on some archs this overhead can be substantial; on others it's
trivial.
|
|
analogous to commit 646cb9a4a04e5ed78e2dd928bf9dc6e79202f609 for sh.
|
|
these are perfectly fine with ld-time symbol binding, but otherwise
result in textrels. they cannot be replaced with @PLT jump targets
because the PLT thunks require a GOT register to be setup, so use a
hidden alias instead.
|
|
analogous to commit 646cb9a4a04e5ed78e2dd928bf9dc6e79202f609 for sh.
|
|
these are perfectly fine with ld-time symbol binding, but if the calls
go through a PLT thunk, they are invalid because the caller does not
setup a GOT register. use a hidden alias to bypass the issue.
|
|
analogous to commit 8ed66ecbcba1dd0f899f22b534aac92a282f42d5 for i386.
|
|
none of these are actual textrels because of ld-time binding performed
by -Bsymbolic-functions, but I'm changing them with the goal of making
ld-time binding purely an optimization rather than relying on it for
semantic purposes.
in the case of memmove's call to memcpy, making it explicit that the
memmove asm is assuming the forward-copying behavior of the memcpy asm
is desirable anyway; in case memcpy is ever changed, the semantic
mismatch would be apparent while editing memmcpy.s.
|
