Rather than generate wasm.syms from wasm.js (which includes
a huge superset of the number of symbols actaully expected
to be undefined at link time) simply hardcode that list as
a test file, which lld can read.
Loading of shared libraries was broken back in:
39fde60
This change restores the ability for shared libraries to
be loaded such that they can share memory and provide
function exports to the main executable.
However the executable that libraries still need to built
in a specific way (i.e. all importing the same sized memory)
and their static globals need to be in the different address
range. This has the complication that the executables won't
run the wasm spec interpreter (since it doesn't pass in a
memory to the executables it runs). So although I'm fixing this
here in the musl repo I'm also proposiing that we remove the
continuous testing of this configurations on the wasm waterfall
in favor of concentrating on the statically linking lld case:
WebAssembly/waterfall#271
s390 can use the generic ioctls definitions other than FIOQSIZE (like arm).
this fixes some missing ioctls and two incorrect ones:
TIOCTTYGSTRUCT and TIOCM_MODEM_BITS seem to be defined on frv
target only in linux.
hwcap bits for armv8.3 extensions, added in linux commits
c8c3798d2369e4285da44b244638eafe446a8f8a
cb567e79fa504575cb97fb2f866d2040ed1c92e7
c651aae5a7732287c1c9bc974ece4ed798780544
This allows a list of all symbols exports by wasm.js to be
generated which is usefull for passing to my prototype of
lld which takes an --allow-undefined-symbols=<filename>
argument.
commit 06fbefd100 (first included in
release 1.1.17) introduced this regression.
patch by Adrian Bunk. it fixes the regression in all cases, but
spuriously prevents use of the clz instruction on very old compiler
versions that don't define __ARM_ARCH. this may be fixed in a more
general way at some point in the future. it also omits thumb1 logic
since building as thumb1 code is currently not supported.
most of the found naming differences don't matter to musl, because
internally it unifies the syscall names that vary across targets,
but for external code the names should match the kernel uapi.
aarch64:
__NR_fstatat is called __NR_newfstatat in linux.
__NR_or1k_atomic got mistakenly copied from or1k.
arm:
__NR_arm_sync_file_range is an alias for __NR_sync_file_range2
__NR_fadvise64_64 is called __NR_arm_fadvise64_64 in linux,
the old non-arm name is kept too, it should not cause issues.
(powerpc has similar nonstandard fadvise and it uses the
normal name.)
i386:
__NR_madvise1 was removed from linux in commit
303395ac3bf3e2cb488435537d416bc840438fcb 2011-11-11
microblaze:
__NR_fadvise, __NR_fstatat, __NR_pread, __NR_pwrite
had different name in linux.
mips:
__NR_fadvise, __NR_fstatat, __NR_pread, __NR_pwrite, __NR_select
had different name in linux.
mipsn32:
__NR_fstatat is called __NR_newfstatat in linux.
or1k:
__NR__llseek is called __NR_llseek in linux.
the old name is kept too because that's the name musl uses
internally.
powerpc:
__NR_{get,set}res{gid,uid}32 was never present in powerpc linux.
__NR_timerfd was briefly defined in linux but then got renamed.
Glibc renamed the linux uapi HWCAP_* macros to HWCAP_ARM_*
so have both variants in case some code depends on it.
(The HWCAP2_ macros are not defined in glibc currently so those
only have the linux uapi variant.)
counts leading zero bits of a 64bit int, undefined on zero input.
(has nothing to do with atomics, added to atomic.h so target specific
helper functions are together.)
there is a logarithmic generic implementation and another in terms of
a 32bit a_clz_32 on targets where that's available.
it is defined in linux asm/sockios.h since commit
ae40eb1ef30ab4120bd3c8b7e3da99ee53d27a23 (linux v2.6.22)
but was missing from musl by accident.
in musl the sockios macros are exposed in sys/ioctl.h together
with other ioctl requests instead of in sys/socket.h because of
namespace rules. (glibc has them in sys/socket.h under _GNU_SOURCE.)
Due to a missing ":" in an asm() statement, the "memory" clobber is
considered by gcc as an input operand and not a clobber, which causes a
build failure.
at one point, clang reportedly failed to support the asm register
constraints needed for inline syscalls. versions of clang that old
have much bigger problems that preclude using them to compile musl
libc.
mips64 requires 'struct stat' conversion due to incorrect 32-bit
fields where time_t should be in the kernel version of the structure.
syscall_arch.h already performed the correct translation for stat,
fstat, and lstat syscalls, but omitted special handling for fstatat.
This structure was missed when creating the s390x port.
This is based on the report and patch from William Pitcock, but with a
modified structure defintion to more closely match the kernel's
definition.
Including sys/procfs.h complains unknown type name 'fpreg_t' in
bits/user.h. fpreg_t in bits/signal.h and elf_fpreg_t in bits/user.h
are practically the same.
per_struct is never used, even conflicts with kernel header
asm/ptrace.h
the 32-bit pc-relative address for stage 2 of dynamic linker entry was
wrongly loaded with a zero-extending load instead of sign-extending
load, resulting in an invalid jump if the offset happened to be
negative, which depends on the linker's ordering of text sections.
the ABI for arm was silently changed at some point to allow page sizes
other than 4k; traditional binaries built with only 4k-aligned offsets
between load segments cannot run on such systems, but newer binutils
versions use 64k offset alignment.
while larger page size is undesirable for various reasons, users have
encountered hardware and/or kernels that lock the page size to a
larger value, so follow the new ABI and allow it to vary.
when _GNU_SOURCE is defined, which is always the case when compiling
c++ with gcc, these macros for the the indices in gregset_t are
exposed and likely to clash with applications. by using enum constants
rather than macros defined with integer literals, we can make the
clash slightly less likely to break software. the macros are still
defined in case anything checks for them with #ifdef, but they're
defined to expand to themselves so that non-file-scope (e.g.
namespaced) identifiers by the same names still work.
for the sake of avoiding mistakes, the changes were generated with sed
via the command:
sed -i -e 's/#define *\(REG_[A-Z_0-9]\{1,\}\) *\([0-9]\{1,\}\)'\
'/enum { \1 = \2 };\n#define \1 \1/' \
arch/i386/bits/signal.h arch/x86_64/bits/signal.h arch/x32/bits/signal.h
three problems are addressed:
- use of pc arithmetic, which was difficult if not impossible to make
correct in thumb mode on all models, so that relative rather than
absolute pointers to the backends could be used. this was designed
back when there was no coherent model for the early stages of the
dynamic linker before relocations, and is no longer necessary.
- assumption that data (the relative pointers to the backends) can be
accessed at a constant displacement from the code. this will not be
possible on future fdpic subarchs (for cortex-m), so move
responsibility for loading the backend code address to the caller.
- hard-coded arm opcodes using the .word directive. instead, use the
.arch directive to work around the assembler's refusal to assemble
instructions not available (or in some cases, available but just
considered deprecated) in the target isa level. the obscure v6t2
arch is used for v6 code so as to (1) allow generation of thumb2
output if -mthumb is active, and (2) avoid warnings/errors for mcr
barriers that clang would produce if we just set arch to v7-a.
in addition, the __aeabi_read_tp function is moved out of the inner
workings and implemented as an asm wrapper around a C function, so
that asm code does not need to read global data. the asm wrapper
serves to satisfy the ABI calling convention requirements for this
function.
