STB_WEAK is only a weak reference for undefined symbols (those with a
section of SHN_UNDEF). otherwise, it's a weak definition. normally
this distinction would not matter, since a relocation referencing a
symbol that also provides a definition (not SHN_UNDEF) will always
succeed in finding the referenced symbol itself. however, in the case
of copy relocations, the referenced symbol itself is ignored in order
to search for another symbol to copy from, and thus it's possible that
no definition is found. in this case, if the symbol being resolved
happened to be a weak definition, it was misinterpreted as a weak
reference, suppressing the error path and causing a crash when the
copy relocation was performed with a null source pointer passed to
memcpy.
there are almost certainly still situations in which invalid
combinations of symbol and relocation types can cause the dynamic
linker to crash (this is pretty much inevitable), but the intent is
that crashes not be possible for symbol/relocation tables produced by
a valid linker.
setstate could use the results of previous initstate or setstate
calls (they return the old state buffer), but the documentation
requires that an initialized state buffer should be possible to
use in setstate immediately, which means that initstate should
save the generator parameters in it.
I also removed the copyright notice since it is present in the
copyright file.
install.sh was wrongly waiting until after atomically replacing the
old file to set the correct permissions on the new file. in the case
of the dynamic linker, this would cause a dynamic-linked chmod command
not to run (due to missing executable permissions on the dynamic
linker) and thus leave the system in an unusable state.
even if chmod is static-linked, the old behavior had a race window
where dynamic-linked programs could fail to run.
the operand size is unnecessary, since the assembler knows it from the
destination register size. removing the suffix makes it so the same
code should work for x32.
in fixing this, I've changed the logic from ugly #if/#else blocks
inside the struct shm_info definition to a fixed struct definition and
optional macros to rename the elements. this will be helpful if we
need to move shm_info to a bits header in the future, as it will keep
the feature test logic out of bits.
the fix should be complete on archs that use the generic definitions
(i386, arm, x86_64, microblaze), but mips and powerpc have not been
checked thoroughly and may need more fixes.
the imr_, imsf_, ip6_, ip6m_, ipi_, ipi6_, SCM_, and SOL_ prefixes are
not in the reserved namespace for this header. thus the constants and
structures using them need to be protected under appropriate feature
test macros.
this also affects some headers which are permitted to include
netinet/in.h, particularly netdb.h and arpa/inet.h.
the SOL_ macros are moved to sys/socket.h where they are in the
reserved namespace (SO*). they are still accessible via netinet/in.h
since it includes sys/socket.h implicitly (which is permitted).
the SCM_SRCRT macro is simply removed, since the definition used for
it, IPV6_RXSRCRT is not defined anywhere. it could be re-added, this
time in sys/socket.h, if the appropriate value can be determined;
however, given that the erroneous definition was not caught, it is
unlikely that any software actually attempts to use SCM_SRCRT.
per POSIX, the variadic argument has type union semun, which may
contain a pointer or int; the type read depends on the command being
issued. this allows the userspace part of the implementation to be
type-correct without requiring special-casing for different commands.
the kernel always expects to receive the argument interpreted as
unsigned long (or equivalently, a pointer), and does its own handling
of extracting the int portion from the representation, as needed.
this change fixes two possible issues: most immediately, reading the
argument as a (signed) long and passing it to the syscall would
perform incorrect sign-extension of pointers on the upcoming x32
target. the other possible issue is that some archs may use different
(user-space) argument-passing convention for unions, preventing va_arg
from correctly obtaining the argument when the type long (or even
unsigned long or void *) is passed to it.
really, fcntl should be changed to use the correct type corresponding
to cmd when calling va_arg, and to carry the correct type through
until making the syscall. however, this greatly increases binary size
and does not seem to offer any benefits except formal correctness, so
I'm holding off on that change for now.
the minimal changes made in this patch are in preparation for addition
of the x32 port, where the syscall macros need to know whether their
arguments are pointers or integers in order to properly pass them to
the 64-bit kernel.
it's unclear what the historical signature for this function was, but
semantically, the argument should be a pointer to const, and this is
what glibc uses. correct programs should not be using this function
anyway, so it's unlikely to matter.
this change is consistent with the corresponding glibc functions and
is semantically const-correct. the incorrect argument types without
const seem to have been taken from erroneous man pages.
this functionality has essentially always been deprecated in linux,
and was never supported by musl. the presence of the header was
reported to cause some software to attempt to use the nonexistant
function, so removing the header is the cleanest solution.
this was wrong since the original commit adding inotify, and I don't
see any explanation for it. not even the man pages have it wrong. it
was most likely a copy-and-paste error.
this practice came from very early, before internal/syscall.h defined
macros that could accept pointer arguments directly and handle them
correctly. aside from being ugly and unnecessary, it looks like it
will be problematic when we add support for 32-bit ABIs on archs where
registers (and syscall arguments) are 64-bit, e.g. x32 and mips n32.
this agrees with implementation practice on glibc and BSD systems, and
is the const-correct way to do things; it eliminates warnings from
passing pointers to const. the prototype without const came from
seemingly erroneous man pages.
the header is included only as a guard to check that the declaration
and definition match, so the typo didn't cause any breakage aside
from omitting this check.
the reasons are the same as for sbrk. unlike sbrk, there is no safe
usage because brk does not return any useful information, so it should
just fail unconditionally.
use of sbrk is never safe; it conflicts with malloc, and malloc may be
used internally by the implementation basically anywhere. prior to
this change, applications attempting to use sbrk to do their own heap
management simply caused untrackable memory corruption; now, they will
fail with ENOMEM allowing the errors to be fixed.
sbrk(0) is still permitted as a way to get the current brk; some
misguided applications use this as a measurement of their memory
usage or for other related purposes, and such usage is harmless.
eventually sbrk may be re-added if/when malloc is changed to avoid
using the brk by using mmap for all allocations.
ssi_ptr is really 64-bit in kernel, so fix that. assuming sizeof(void*)
for it also caused incorrect padding for 32-bits, as the following
64-bits are aligned to 64-bits (and the padding was not taken into
account), so fix the padding as well. add addr_lsb field while there.
the workaround/fallback code for supporting O_PATH file descriptors
when the kernel lacks support for performing these operations on them
caused EBADF to get replaced by ENOENT (due to missing entry in
/proc/self/fd). this is unlikely to affect real-world code (calls that
might yield EBADF are generally unsafe, especially in library code)
but it was breaking some test cases.
the fix I've applied is something of a tradeoff: it adds one syscall
to these operations on kernels where the workaround is needed. the
alternative would be to catch ENOENT from the /proc lookup and
translate it to EBADF, but I want to avoid doing that in the interest
of not touching/depending on /proc at all in these functions as long
as the kernel correctly supports the operations. this is following the
general principle of isolating hacks to code paths that are taken on
broken systems, and keeping the code for correct systems completely
hack-free.
the ABI allows the callee to clobber stack slots that correspond to
arguments passed in registers, so the caller must adjust the stack
pointer to reserve space appropriately. prior to this fix, the argv
array was possibly clobbered by dynamic linker code before passing
control to the main program.
our getcwd already (as an extension) supports allocation of a buffer
when the buffer argument is a null pointer, so there's no need to
duplicate the allocation logic in this wrapper function. duplicating
it is actually harmful in that it doubles the stack usage from
PATH_MAX to 2*PATH_MAX.
the wildcard function in GNU make includes dangling symlinks; if any
exist under the .git directory, they would get added as dependencies,
causing make to exit with an error due to lacking a rule to build the
missing file.
as far as I can tell, git operations which should force version.h to
be rebuilt must all touch the mtime of the top-level .git directory.
historically these functions appeared in BSD 4.3 without prototypes,
then in the bind project prototypes were added to resolv.h, but those
were incompatible with the definitions of the implementation.
the bind resolv.h became the defacto api most systems use now, but the
old internal definitions found their way into the linux manuals and thus
into musl.
