| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
mxcs_mask should be mxcr_mask
(cherry picked from commit 4758f0565df83beb8f9b24857ec40ca3a40d2281)
|
|
|
|
|
|
|
|
|
|
| |
due to what was essentially a copy and paste error, the changes made
in commit f61be1f875a2758509d6e9e2cf6f1d9603b28b65 caused syscalls
with 5 or 6 arguments (and syscalls with 2, 3, or 4 arguments when
compiled with clang compatibility) to negate the returned error code a
second time, breaking errno reporting.
(cherry picked from commit 1312930f9bdea47006a8a8c8509c0bed5cf69e85)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the mips version of this structure on the kernel side wrongly has
32-bit type rather than 64-bit type. fortunately there is adjacent
padding to bring it up to 64 bits, and on little-endian, this allows
us to treat the adjacent kernel st_dev and st_pad0[0] as as single
64-bit dev_t. however, on big endian, such treatment results in the
upper and lower 32-bit parts of the dev_t value being swapped. for the
purpose of just comparing st_dev values this did not break anything,
but it precluded actually processing the device numbers as major/minor
values.
since the broken kernel behavior that needs to be worked around is
isolated to one arch, I put the workarounds in syscall_arch.h rather
than adding a stat fixup path in the common code. on little endian
mips, the added code optimizes out completely.
the changes necessary were incompatible with the way the __asm_syscall
macro was factored so I just removed it and flattened the individual
__syscallN functions. this arguably makes the code easier to read and
understand, anyway.
(cherry picked from commit f61be1f875a2758509d6e9e2cf6f1d9603b28b65)
|
|
|
|
| |
(cherry picked from commit 522a0de2101abd12b19a4d2ba5c09abbb7c5fc79)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as far as I can tell, microblaze is strongly ordered, but this does
not seem to be well-documented and the assumption may need revisiting.
even with strong ordering, however, a volatile C assignment is not
sufficient to implement atomic store, since it does not preclude
reordering by the compiler with respect to non-volatile stores and
loads.
simply flanking a C store with empty volatile asm blocks with memory
clobbers would achieve the desired result, but is likely to result in
worse code generation, since the address and value for the store may
need to be spilled. actually writing the store in asm, so that there's
only one asm block, should give optimal code generation while
satisfying the requirement for having a compiler barrier.
(cherry picked from commit 884cc0c7e253601b96902120ed689f34d12f8aa0)
|
|
|
|
| |
(cherry picked from commit 1456b7ae6b72a4f2c446243acdde7c951268d4ab)
|
|
|
|
|
|
|
|
|
|
| |
previously I had wrongly assumed the ll/sc instructions also provided
memory synchronization; apparently they do not. this commit adds sync
instructions before and after each atomic operation and changes the
atomic store to simply use sync before and after a plain store, rather
than a useless compare-and-swap.
(cherry picked from commit bcad48439494820989f5867c3f8ccfa6aae2909f)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
despite lacking the semantic content that the asm accesses the
pointed-to object rather than just using its address as a value, the
mips asm was not actually broken. the asm blocks were declared
volatile, meaning that the compiler must treat them as having unknown
side effects.
however changing the asm to use memory constraints is desirable not
just from a semantic correctness and consistency standpoint, but also
produces better code. the compiler is able to use base/offset
addressing expressions for the atomic object's address rather than
having to load the address into a single register. this improves
access to global locks in static libc, and access to non-zero-offset
atomic fields in synchronization primitives, etc.
(cherry picked from commit a294f539c78c6ba0a2786ef3c5b2a1210a33864e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
due to a mistake in my testing procedure, the changes in the previous
commit were not correctly tested and wrongly assumed to be valid. the
lwarx and stwcx. instructions do not accept general ppc memory address
expressions and thus the argument associated with the memory
constraint cannot be used directly.
instead, the memory constraint can be left as an argument that the asm
does not actually use, and the address can be provided in a separate
register constraint.
(cherry picked from commit bb3a3befeaa01531c273ef9130f3fbcaaf8a25e2)
|
|
|
|
| |
(cherry picked from commit 94252dd341a7c72b31db2614abdc74142ad80562)
|
|
|
|
|
|
|
|
|
|
| |
the register constraint for the address to be accessed did not convey
that the asm can access the pointed-to object. as far as the compiler
could tell, the result of the asm was just a pure function of the
address and the values passed in, and thus the asm could be hoisted
out of loops or omitted entirely if the result was not used.
(cherry picked from commit 7fdae458bd421046a300a69dcb32953ac9450136)
|
|
|
|
|
|
|
|
| |
the erroneous definition was missed because with works with qemu
user-level emulation, which also has the wrong definition. the actual
kernel uses the asm-generic generic definition.
(cherry picked from commit d69ab5b3686acf75fdf5db6fad19c2c6a510bb4f)
|
|
|
|
|
|
|
|
|
| |
processing of R_PPC_TPREL32 was ignoring the addend provided by the
RELA-style relocation and instead using the inline value as the
addend. this presumably broke dynamic-linked access to initial TLS in
cases where the addend was nonzero.
(cherry picked from commit 94cf991bf4b18bb87a15a96e7b5e7d92fab787ba)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On 32 bit mips the kernel uses -1UL/2 to mark RLIM_INFINITY (and
this is the definition in the userspace api), but since it is in
the middle of the valid range of limits and limits are often
compared with relational operators, various kernel side logic is
broken if larger than -1UL/2 limits are used. So we truncate the
limits to -1UL/2 in get/setrlimit and prlimit.
Even if the kernel side logic consistently treated -1UL/2 as greater
than any other limit value, there wouldn't be any clean workaround
that allowed using large limits:
* using -1UL/2 as RLIM_INFINITY in userspace would mean different
infinity value for get/setrlimt and prlimit (where infinity is always
-1ULL) and userspace logic could break easily (just like the kernel
is broken now) and more special case code would be needed for mips.
* translating -1UL/2 kernel side value to -1ULL in userspace would
mean that -1UL/2 limit cannot be set (eg. -1UL/2+1 had to be passed
to the kernel instead).
(cherry picked from commit 8258014fd1e34e942a549c88c7e022a00445c352)
|
|
|
|
| |
(cherry picked from commit 468bc11ed059c475f974920ac3d499e6071a6b2c)
|
|
|
|
|
|
|
|
|
| |
The mips arch is special in that it uses different RLIMIT_
numbers than other archs, so allow bits/resource.h to override
the default RLIMIT_ numbers (empty on all archs except mips).
Reported by orc.
(cherry picked from commit fcea534e579077e10456f6ed06c033dfaa013a24)
|
|
|
|
|
|
|
|
|
|
|
| |
the kernel entry point for syscalls on microblaze nominally saves and
restores all registers, and testing on qemu always worked since qemu
behaves this way too. however, the real kernel treats r3:r4 as a
potential 64-bit return value from the syscall function, and copies
both over top of the saved registers before returning to userspace.
thus, we need to treat r4 as always-clobbered.
(cherry picked from commit 91d5aa06572d2660122f9a06ed242fef0383f292)
|
|
|
|
|
|
| |
in the previous changes, I missed the fact that both the prototype of
the sigaltstack function and the definition of ucontext_t depend on
stack_t.
|
|
|
|
| |
like almost everything on mips, this is gratuitously different.
|
|
|
|
|
| |
it's different at least on mips. mips version will be fixed in a
separate commit to show the change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the excess space was unused and unintentional. this change does not
affect the ABI between applications and libc. while it does
theoretically affect linkage between third-party translation units
using jmp_buf as part of a structure, we've already changed jmp_buf at
least once on all archs, and problems were never observed, likely
because such usage would be very unusual. in any case it's best to get
things right now rather than making changes sometime during the 1.0.x
series or later.
|
|
|
|
|
|
| |
this seems to have been copied erroneously from the arm version of the
file. it's fairly harmless but it's a mistake and better to fix now
than later.
|
|
|
|
|
| |
the omission of the padding was uncovered by the latest regression
statvfs regression test added to libc-test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Applications ended up with copy relocations for this array, which
resulted in libc's references to this array pointing to the
application's copy. The dynamic linker, however, can require this array
before the application is relocated, and therefore before the
application's copy of this array is initialized. This resulted in
garbage being loaded into FPSCR before executing main, which violated
the ABI.
We fix this by putting the array in crt1 and making the libc copy
private. This prevents libc's reference to the array from pointing to
an uninitialized copy in the application.
|
|
|
|
|
|
| |
The mips statfs struct layout is different than on other archs, so the
statfs, fstatfs, statvfs and fstatvfs APIs were broken on mips.
Now the ordering is fixed, the types are kept consistent with other archs.
|
|
|
|
|
| |
This used to be broken when all archs had the same semid_ds definition:
there is no padding around the time_t members on mips.
|
|
|
|
|
|
| |
these were incorrectly copied from the kernel, whose ABI matches the
POSIX requirements but with the wrong underlying types and wrong
signedness.
|
|
|
|
|
|
|
|
| |
these have been wrong for a long time and were never detected or
corrected. powerpc needs some gratuitous extra padding/reserved slots
in ipc_perm, big-endian ordering for the padding of time_t slots that
was intended by the kernel folks to allow a transition to 64-bit
time_t, and some minor gratuitous reordering of struct members.
|
|
|
|
|
|
|
|
|
|
|
|
| |
the definition was found to be incorrect at least for powerpc, and
fixing this cleanly requires making the definition arch-specific. this
will allow cleaning up the definition for other archs to make it more
specific, and reversing some of the ugliness (time_t hacks) introduced
with the x32 port.
this first commit simply copies the existing definition to each arch
without any changes. this is intentional, to make it easier to review
changes made on a per-arch basis.
|
|
|
|
|
| |
this seems to have been overlooked, and resulted in breakage in
anything including sys/user.h.
|
|
|
|
|
|
|
|
| |
the kernel uses long longs in the struct, but the documentation
says they're long. so we need to fixup the mismatch between the
userspace and kernelspace structs.
since the struct offers a mem_unit member, we can avoid truncation
by adjusting that value.
|
| |
|
|
|
|
|
| |
default endianness for sh on linux is little, and while conventions
vary, "eb" seems to be the most widely used suffix for big endian.
|
|
|
|
|
|
|
|
|
| |
linux, gcc, etc. all use "sh" as the name for the superh arch. there
was already some inconsistency internally in musl: the dynamic linker
was searching for "ld-musl-sh.path" as its path file despite its own
name being "ld-musl-superh.so.1". there was some sentiment in both
directions as to how to resolve the inconsistency, but overall "sh"
was favored.
|
|
|
|
|
|
|
|
|
| |
Userspace emulated floating-point (gcc -msoft-float) is not compatible
with the default mips abi (assumes an FPU or in kernel emulation of it).
Soft vs hard float abi should not be mixed, __mips_soft_float is checked
in musl's configure script and there is no runtime check. The -sf subarch
does not save/restore floating-point registers in setjmp/longjmp and only
provides dummy fenv implementation.
|
|
|
|
|
|
|
|
|
| |
the reordering of headers caused some risc archs to not see
the __syscall declaration anymore.
this caused build errors on mips with any compiler,
and on arm and microblaze with clang.
we now declare it locally just like the powerpc port does.
|
|
|
|
|
| |
previously it was wrongly using the x86_64 one, precluding having both
x32 and x86_64 libs present on the same system.
|
| |
|
|
|
|
|
|
|
|
| |
it's legal to call the __syscall functions with more arguments than
necessary, and the __syscall_cp cancel dummy impl. does just that.
thus we must insert the switch for all possible syscalls numbers
into all of the syscallN inline functions.
|
|
|
|
|
|
| |
- the nanosleep fixup "fixed" the second timespec* argument erroneusly.
- the futex fixup was missing the check for FUTEX_WAIT.
- general cleanup using a macro.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
aside from general cleanup, this should allow the identical atomic.h
file to be used for the upcoming x32 port.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
otherwise it's unclear that it's correct. aside from that, it makes
for a gratuitous difference between the x86_64 header and the upcoming
x32 header.
|
| |
|