| Commit message (Collapse) | Author | Files | Lines |
|---|
|
based on patch by Denys Vlasenko. the original intent for using these
options was to enable linking optimizations. these are immediately
available for static linking applications to libc.a, and will also be
used for linking libc.so in a subsequent commit.
in addition to the original motives, this change works around a whole
class of toolchain bugs where the compiler generates relative address
expressions using a weak symbol and the assembler "optimizes out" the
relocation which should result by using the weak definition. (see gas
pr 18561 and gcc pr 66609, 68178, etc. for examples.) by having
different functions and data objects in their own sections, all
relative address expressions are cross-section and thus cannot be
resolved to constants until link time. this allows us to retain
support for affected compiler/assembler versions without invasive
and fragile source-level workarounds.
|
|
this conditional path was never tested because there are no compilers
that conform to annex g (none with _Imaginary_I).
|
|
this assumption is borderline-unsafe to begin with, and fails badly
with -ffunction-sections since the linker can move the callee
arbitrarily far away when it lies in a different section.
|
|
this way, overriding these variables on the make command line (or just
re-passing the originally-passed values when invoking make) won't
suppress use of the flags added by configure.
|
|
since mremap with the MREMAP_FIXED flag is an operation that unmaps
existing mappings, it needs to use the vm lock mechanism to ensure
that any in-progress synchronization operations using vm identities
from before the call have finished.
also, the variadic argument was erroneously being read even if the
MREMAP_FIXED flag was not passed. in practice this didn't break
anything, but it's UB and in theory LTO could turn it into a hard
error.
|
|
It's quite feasible for this to happen via MREMAP_MAYMOVE.
|
|
previously, only archs that needed to do stack cleanup defined a
__cp_cancel label for acting on cancellation in their syscall asm, and
a default definition was provided by a weak alias to __cancel, the C
function. this resulted in wrong codegen for arm on gcc versions
affected by pr 68178 and possibly similar issues (like pr 66609) on
other archs, and also created an inconsistency where the __cp_begin
and __cp_end labels were treated as const data but __cp_cancel was
treated as a function. this in turn caused incorrect code generation
on archs where function pointers point to function descriptors rather
than code (for now, only sh/fdpic).
|
|
using the actual mcontext_t definition rather than an overlaid pointer
array both improves correctness/readability and eliminates some ugly
hacks for archs with 64-bit registers bit 32-bit program counter.
also fix UB due to comparison of pointers not in a common array
object.
|
|
when a library being loaded has bss (i.e. data segment with
p_memsz>p_filesz), this region needs to be zeroed with a combination
of memset and/or mmap. the regular ELF loader always did this but the
FDPIC code path omitted it, leading to objects in bss having
uninitialized/junk contents.
|
|
getnameinfo() compares the size of the given struct sockaddr with
sizeof(struct sockaddr_in) and sizeof(struct sockaddr_in6) depending on
the net family. When you add a sockaddr of size sizeof(struct
sockaddr_storage) this function will fail because the size of the
sockaddr is too big. Change the check that it only fails if the size is
too small, but make it work when it is too big for example when someone
calls this function with a struct sockaddr_storage and its size.
This fixes a problem with IoTivity 1.0.0 and musl.
glibc and bionic are only failing if it is smaller, net/freebsd
implemented the != check.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
|
|
previously, transient failures like fd exhaustion or other
resource-related errors were treated the same as non-existence of
these files, leading to fallbacks or false-negative results. in
particular:
- failure to open hosts resulted in fallback to dns, possibly yielding
EAI_NONAME for a hostname that should be defined locally, or an
unwanted result from dns that the hosts file was intended to
replace.
- failure to open services resulted in EAI_SERVICE.
- failure to open resolv.conf resulted in querying localhost rather
than the configured nameservers.
now, only permanent errors trigger the fallback behaviors above; all
other errors are reportable to the caller as EAI_SYSTEM.
|
|
the buffer enlargement logic here accounted for the terminating null
byte, but not for the possibility of hitting the delimiter in the
buffer-refill code path that uses getc_unlocked, in which case two
additional bytes (the delimiter and the null termination) are written
without another chance to enlarge the buffer.
this patch and the corresponding bug report are by Felix Janda.
|
|
the option to suppress executable stack tagging was placed in CFLAGS,
which is treated as optional and overridable by the build system. if a
user replaces CFLAGS after configure has run, it could get lost,
resulting in a libc.so that's flagged as needing executable stack,
which would cause the kernel to map the initial stack as executable.
move -Wa,--noexecstack to CFLAGS_C99FSE, the make variable used for
mandatory compiler options.
|
|
these per-target CFLAGS adjustments are mandatory additions to the
command line for building the affected targets, not part of the
user-provided CFLAGS for tuning. my intent was always that the
variable append operations would take place after user settings, but
when a variable is set on the command line, it overrides all
definitions in the makefile, including target-specific ones.
based on patch by Szabolcs Nagy.
|
|
|
|
Some armhf gcc toolchains (built with --with-float=hard but without
--with-fpu=vfp*) do not pass -mfpu=vfp to the assembler and then
binutils rejects the UAL mnemonics for VFP unless there is an .fpu vfp
directive in the asm source.
|
|
POSIX requires pthread_join to synchronize memory on success. The
futex wait inside __timedwait_cp cannot handle this because it's not
called in all cases. Also, in the case of a spurious wake, tid can
become zero between the wake and when the joining thread checks it.
|
|
when determining which module an address belongs to, all function
descriptor ranges must be checked first, in case the allocated memory
falls inside another module's memory range.
dladdr itself must also check addresses against function descriptors
before doing a best-match search against the symbol table. even when
doing the latter (e.g. for code addresses obtained from mcontext_t),
also check whether the best-match was a function, and if so, replace
the result with a function descriptor address. which is the nominal
"base address" of the function and which the caller needs if it
intends to subsequently call the matching function.
|
|
since commits 2907afb8dbd4c1d34825c3c9bd2b41564baca210 and
6fc30c2493fcfedec89e45088bea87766a1e3286, __dls2 is no longer called
via symbol lookup, but instead uses relative addressing that needs to
be resolved at link time. on some linker versions, and/or if
-Bsymbolic-functions is not used, the linker may leave behind a
dynamic relocation, which is not suitable for bootstrapping the
dynamic linker, if the reference to __dls2 is marked hidden but the
definition is not actually hidden. correcting the definition to use
hidden visibility fixes the problem.
the static-PIE entry point rcrt1 was likewise affected and is also
fixed by this patch.
|
|
we need access to all instructions in order for runtime selection of
atomic model to work correctly. without this patch, some versions of
gcc instruct gas to reject instructions outside the target isa level.
|
|
other archs use asm for the thread pointer load, so making that asm
volatile is sufficient to inform the compiler that it has a "side
effect" (crashing or giving the wrong result if the thread pointer was
not yet initialized) that prevents reordering. however, powerpc and
or1k have dedicated general purpose registers for the thread pointer
and did not need to use any asm to access it; instead, "local register
variables with a specified register" were used. however, there is no
specification for ordering constraints on this type of usage, and
presumably use of the thread pointer could be reordered across its
initialization.
to impose an ordering, I have added empty volatile asm blocks that
produce the "local register variable with a specified register" as
an output constraint.
|
|
this builds on commits a603a75a72bb469c6be4963ed1b55fabe675fe15 and
0ba35d69c0e77b225ec640d2bd112ff6d9d3b2af to ensure that a compiler
cannot conclude that it's valid to reorder the asm to a point before
the thread pointer is set up, or to treat the inline function as if it
were declared with attribute((const)).
other archs already use volatile asm for thread pointer loading.
|
|
|
|
commit a603a75a72bb469c6be4963ed1b55fabe675fe15 did this for the
public pthread_self function but not the internal inline one.
|
|
strftime results are unspecified in this case, but should not invoke
undefined behaviour.
tm_wday, tm_yday, tm_mon and tm_year fields were used in signed int
arithmetic that could overflow.
based on patch by Szabolcs Nagy.
|
|
since commit c5e34dabbb47d8e97a4deccbb421e0cd93c0094b, crt1.c has
provided a "mostly-C" implementation of the crt1 start file that
avoids the need for arch-specific symbol referencing, PIC/PIE-specific
code variants, etc. but for archs that had existing hand-written
versions, the new code was initially unused, and later only used as
the dynamic linker entry point. this commit switches all archs to
using the new code.
the code being removed was a recurring source of subtle errors, and
was still broken at least on arm, where it failed to properly align
the stack pointer before calling into C code.
|
