about summary refs log tree commit diff
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* reintroduce riscv64 struct sigcontextRich Felker2019-10-021-6/+10
| | | | | | | | commit ab3eb89a8b83353cdaab12ed017a67a7730f90e9 removed it as part of correcting the mcontext_t definition, but there is still code using struct sigcontext and expecting the member names present in it, most notably libgcc_eh. almost all such usage is incorrect, but bring back struct sigcontext at least for now so as not to introduce regressions.
* fix riscv64 elf_fpregset_t type and member names mismatchRich Felker2019-09-291-5/+2
| | | | | | | | | | | | | | | | | in order for sys/procfs.h (provided by sys/user.h) to be useful, it needs to match the API its consumers (gdb, etc.) expect, including the member names established by glibc. this partly reverts commit 29e8737f81ccc9fbadcf61a75318aa3d0516aafa, which partly reverted d493206de7df4db07ad34f24701539ba0a6ed38c, eliminating struct user_fpregs_struct which seems to have had no precedent and using union __riscv_mc_fp_state for elf_fpregset_t. this requires indirect inclusion of signal.h to make union __riscv_mc_fp_state visible, but being that these are nonstandard "junk" headers with no official restrictions on what they can pull in, that's no big deal. split off and expanded from patch by Khem Raj.
* fix riscv64 signal.h namespace violations and ucontext API mismatchesRich Felker2019-09-292-27/+20
| | | | | | | | | | | | | | | | | | | | | the top-level mcontext_t member names were namespace-violating in standards profiles before, and nested-level member names (some of them single-letter) were egregiously bad namespace impositions even in non-strict profiles. moreover, they mismatched those used in the public API first defined in glibc, breaking any code making use of them. unlike most archs, the public API used in glibc for riscv mcontext_t members was designed to be namespace-safe, so we can and should expose the members regardless of feature test macros. only the typedefs for greg_t, gregset_t, and fpregset_t need to be protected behind FTMs. the struct tags for mcontext_t and ucontext_t are also changed. for mcontext_t this is necessary to make the common definition across profiles namespace-safe. for ucontext_t, it's just a matter of matching the tag from the glibc-defined API. these changes are split off and expanded from a patch by Khem Raj.
* clean up mips (32-bit, o32) syscall asm constraintsRich Felker2019-09-271-31/+32
| | | | | | | | | | | | | | | | | | | | analogous to commit ddc7c4f936c7a90781072f10dbaa122007e939d0 for mips64 and n32, remove the hack to load the syscall number into $2 via asm, and use a constraint to let the compiler load it instead. now, only $4, $5, and $6 are potential input-only registers. $2 is always input and output, and $7 is both when it's an argument, otherwise output-only. previously, $7 was treated as an input (with a "1" constraint matching its output position) even when it was not an input, which was arguably undefined behavior (asm input from indeterminate value). this is corrected. as before, $8, $9, and $10 are conditionally input-output registers for 5-, 6-, and 7-argument syscalls. their role in input is carrying in the values that will be stored on the stack for arguments 5-7. their role in output is carrying back whatever the kernel has clobbered them with, so that the compiler cannot assume they still contain the input values.
* fix mips r6 syscall clobber lists not to include hi/lo registersRich Felker2019-09-263-16/+30
| | | | | | | | | | mips r6 (an incompatible isa from traditional mips) removes the hi and lo registers used for mul/div results. older gcc versions accepted them in the clobber list for asm, but their presence is incorrect and breaks on later versions. in the process of fixing this, the clobber list for 32-bit mips syscalls has been deduplicated via a macro like on mips64 and n32.
* correct the operand specifiers in the riscv64 CAS routinesPalmer Dabbelt2019-09-251-2/+2
| | | | | | | | | | | | | | | | The operand sepcifiers in a_cas and a_cas_p for riscv64 were incorrect: there's a backwards branch in the routine, so despite tmp being written at the end of the assembly fragment it cannot be allocated in one of the input registers because the input values may be needed for another trip around the loop. For code that follows the guaranteed forward progress requirements, the backwards branch is rarely taken: SiFive's hardware only fails a store conditional on execptional cases (ie, instruction cache misses inside the loop), and until recently a bug in QEMU allowed back-to-back store conditionals to succeed. The bug has been fixed in the latest QEMU release, but it turns out that the fix caused this latent bug in musl to manifest.
* aarch64: add HWCAP2 flags from linux v5.2Szabolcs Nagy2019-09-111-0/+8
| | | | | | | | | | AT_HWCAP2 flags, see linux commit 671db581815faf17cbedd7fcbc48823a247d90b1 arm64: Expose DC CVADP to userspace linux commit 06a916feca2b262ab0c1a2aeb68882f4b1108a07 arm64: Expose SVE2 features for userspace
* add new syscall numbers from linux v5.2Szabolcs Nagy2019-09-1116-0/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | new mount api syscalls were added, same numers on all targets, see linux commit a07b20004793d8926f78d63eb5980559f7813404 vfs: syscall: Add open_tree(2) to reference or clone a mount linux commit 2db154b3ea8e14b04fee23e3fdfd5e9d17fbc6ae vfs: syscall: Add move_mount(2) to move mounts around linux commit 24dcb3d90a1f67fe08c68a004af37df059d74005 vfs: syscall: Add fsopen() to prepare for superblock creation linux commit ecdab150fddb42fe6a739335257949220033b782 vfs: syscall: Add fsconfig() for configuring and managing a context linux commit 93766fbd2696c2c4453dd8e1070977e9cd4e6b6d vfs: syscall: Add fsmount() to create a mount for a superblock linux commit cf3cba4a429be43e5527a3f78859b1bfd9ebc5fb vfs: syscall: Add fspick() to select a superblock for reconfiguration linux commit 9c8ad7a2ff0bfe58f019ec0abc1fb965114dde7d uapi, x86: Fix the syscall numbering of the mount API syscalls [ver #2] linux commit d8076bdb56af5e5918376cd1573a6b0007fc1a89 uapi: Wire up the mount API syscalls on non-x86 arches [ver #2]
* honor __WCHAR_TYPE__ on archs with legacy long definition of wchar_tRich Felker2019-09-084-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | historically, a number of 32-bit archs used long rather than int for wchar_t, for no good reason. GCC still uses the historical types, but clang replaced them all with int, and it seems PCC uses int too. mismatching the compiler's type for wchar_t is not an option due to wide string literals. note that the mismatch does not affect C++ ABI since wchar_t is its own builtin type/keyword in C++, distinct from both int and long, not a typedef. i386 already worked around this by honoring __WCHAR_TYPE__ if defined by the compiler, and only using the official legacy ABI type if not. add the same to the other affected archs. it might make sense at some point to switch to using int as the default if __WCHAR_TYPE__ is not defined, if the expectations is that new compilers will treat int as the correct choice, but it's unlikely that the case where __WCHAR_TYPE__ is undefined will ever be used anyway. I actually wanted to move the definition of wchar_t to the top-level shared alltypes.h.in, using __WCHAR_TYPE__ and falling back to int if not defined, but that can't be done without assuming all compilers define __WCHAR_TYPE__ thanks to some pathological archs where the ABI has wchar_t as an unsigned type.
* fix clash between sys/user.h and kernel ptrace.h on powerpc[64], shRich Felker2019-08-193-41/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | due to historical accident/sloppiness in glibc, the powerpc, powerpc64, and sh versions of struct user, defined by sys/user.h, used struct pt_regs from the kernel asm/ptrace.h for their regs member. this made it impossible to define the type in an API-compatible manner without either including asm/ptrace.h like glibc does (contrary to our policy of not depending on kernel headers), or clashing with asm/ptrace.h's definition of struct pt_regs if both headers are included (which is almost always the case in software using sys/user.h). for a long time I viewed this problem as having no reasonable fix. I even explored the possibility of having the powerpc[64] and sh versions of user.h just include the kernel header (breaking with policy), but that looked like it might introduce new clashes with sys/ptrace.h. and it would also bring in a lot of additional cruft that makes no sense for sys/user.h to expose. glibc goes out of its way to suppress some of that with #undef, possibly leading to different problems. this is a rabbit-hole that should be explored no further. as it turns out, however, nothing actually uses struct user sufficiently to care about the type of the regs member; most software including sys/user.h does not even use struct user at all. so, the problem can be fixed just by doing away with the insistence on strict glibc API compatibility for the struct tag of the regs member. rather than renaming the tag, which might lead to the new name entering use as API, simply use an untagged structure inside struct user with the same members/layout as struct pt_regs. for sh, struct pt_dspregs is just removed entirely since it was not used.
* re-add ELF gregs and fpregs types to riscv64 user.hKhem Raj2019-08-131-0/+8
| | | | | | d493206de7df4db07ad34f24701539ba0a6ed38c deleted all the content of user.h, but sys/procfs.h expects this from sys/user.h threfore we retain the non conflicting parts
* add support for powerpc/powerpc64 unaligned relocationsSamuel Holland2019-08-112-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | R_PPC_UADDR32 (R_PPC64_UADDR64) has the same meaning as R_PPC_ADDR32 (R_PPC64_ADDR64), except that its address need not be aligned. For powerpc64, BFD ld(1) will automatically convert between ADDR<->UADDR relocations when the address is/isn't at its native alignment. This will happen if, for example, there is a pointer in a packed struct. gold and lld do not currently generate R_PPC64_UADDR64, but pass through misaligned R_PPC64_ADDR64 relocations from object files, possibly relaxing them to misaligned R_PPC64_RELATIVE. In both cases (relaxed or not) this violates the PSABI, which defines the relevant field type as "a 64-bit field occupying 8 bytes, the alignment of which is 8 bytes unless otherwise specified." All three linkers violate the PSABI on 32-bit powerpc, where the only difference is that the field is 32 bits wide, aligned to 4 bytes. Currently musl fails to load executables linked by BFD ld containing R_PPC64_UADDR64, with the error "unsupported relocation type 43". This change provides compatibility with BFD ld on powerpc64, and any static linker on either architecture that starts following the PSABI more closely.
* remove riscv64 bits/user.h contentsRich Felker2019-08-061-43/+0
| | | | | | | the contents conflicted with asm/ptrace.h. glibc does not provide anything in user.h for riscv, so software cannot be depending on it. simplified from patch submitted by Baruch Siach.
* fix risc64 conflict with kernel headersBaruch Siach2019-08-061-8/+8
| | | | | | Rename user registers struct definitions to avoid conflict with the asm/ptrace.h kernel header that defines the same structs. Use the __riscv_mc prefix as glibc does.
* update riscv64 syscall numbers to linux v5.1Rich Felker2019-08-031-0/+8
| | | | | | | | commit f3f96f2daa4d00f0e38489fb465cd0244b531abe added these for the rest of the archs, but the patch it corresponded to missed riscv64 since riscv64 was not yet upstream at the time. this caused commit dfc81828f7ab41da08f744c44117a1bb20a05749 to break riscv64 build, due to a wrong assumption that SYS_statx was unconditionally defined.
* move IPC_STAT definition to a new bits/ipcstat.h fileRich Felker2019-08-0210-0/+10
| | | | | | | | | | | | | | | otherwise, 32-bit archs that could otherwise share the generic bits/ipc.h would need to duplicate the struct ipc_perm definition, obscuring the fact that it's the same. sysvipc is not widely used and these headers are not commonly included, so there is no performance gain to be had by limiting the number of indirectly included files here. files with the existing time32 definition of IPC_STAT are added to all current 32-bit archs now, so that when it's changed the change will show up as a change rather than addition of a new file where it's less obvious that the value is changing vs the generic one that was used before.
* ioctl: add fallback for new time64 SIOCGSTAMP[NS]Rich Felker2019-07-311-0/+3
| | | | | | | | | | | without this, the SIOCGSTAMP and SIOCGSTAMPNS ioctl commands, for obtaining timestamps, would stop working on pre-5.1 kernels after time_t is switched to 64-bit and their values are changed to the new time64 versions. new code is written such that it's statically unreachable on 64-bit archs, and on existing 32-bit archs until the macro values are changed to activate 64-bit time_t.
* get/setsockopt: add fallback for new time64 SO_RCVTIMEO/SO_SNDTIMEORich Felker2019-07-315-0/+15
| | | | | | | | | | without this, the SO_RCVTIMEO and SO_SNDTIMEO socket options would stop working on pre-5.1 kernels after time_t is switched to 64-bit and their values are changed to the new time64 versions. new code is written such that it's statically unreachable on 64-bit archs, and on existing 32-bit archs until the macro values are changed to activate 64-bit time_t.
* remove gratuitously-different arch-specific bits/ipc.h filesRich Felker2019-07-303-36/+0
| | | | | | | | these differ from generic only in using endian-matched padding with a short __ipc_perm_seq field in place of the int field in generic. this is not a documented public interface anyway, and the original intent was to use int here. some ports just inadvertently slipped in the kernel short+padding form.
* remove arch-specific bits/ipc.h that are identical to genericRich Felker2019-07-302-22/+0
| | | | | | previously these differed from generic because they needed their own definitions of IPC_64. now that it's no longer in public header, they're identical.
* move IPC_64 from public bits/ipc.h to syscall_arch.hRich Felker2019-07-3015-22/+10
| | | | | | | | | | | | | | | | | | | | the definition of the IPC_64 macro controls the interface between libc and the kernel through syscalls; it's not a public API. the meaning is rather obscure. long ago, Linux's sysvipc *id_ds structures used 16-bit uids/gids and wrong types for a few other fields. this was in the libc5 era, before glibc. the IPC_64 flag (64 is a misnomer; it's more like 32) tells the kernel to use the modern[-ish] versions of the structures. the definition of IPC_64 has nothing to do with whether the arch is 32- or 64-bit. rather, due to either historical accident or intentional obnoxiousness, the kernel only accepts and masks off the 0x100 IPC_64 flag conditional on CONFIG_ARCH_WANT_IPC_PARSE_VERSION, i.e. for archs that want to provide, or that accidentally provided, both. for archs which don't define this option, no masking is performed and commands with the 0x100 bit set will fail as invalid. so ultimately, the definition is just a matter of matching an arbitrary switch defined per-arch in the kernel.
* remove duplicates of new generic bits/msg.hRich Felker2019-07-296-75/+0
|
* use 64-bit msqid_ds layout in the generic version of bits/msg.hRich Felker2019-07-291-3/+0
| | | | | | this layout is more common already than the old generic, and should become even more common in the future with new archs added and with 64-bit time_t on 32-bit archs.
* duplicate generic bits/msg.h for each arch using it, in prep to changeRich Felker2019-07-295-0/+75
|
* remove duplicates of new generic bits/sem.hRich Felker2019-07-295-57/+0
| | | | | | some of these were not exact duplicates, but had gratuitously different naming for padding, or omitted the endian checks because the arch is fixed-endian.
* use 64-bit semid_ds layout in the generic version of bits/sem.hRich Felker2019-07-291-2/+0
| | | | | | | | this layout is slightly less common than the old generic one, but only because x86_64 and x32 wrongly (according to comments in the kernel headers) copied the i386 padding. for future archs, and with 64-bit time_t on 32-bit archs, the new layout here will become the most common, and it makes sense to treat it as the generic.
* collapse out byte order conditions in bits/sem.h for fixed-endian archsRich Felker2019-07-294-20/+0
| | | | | having preprocessor conditionals on byte order in the bits headers for fixed-endian archs is confusing at best. remove them.
* duplicate generic bits/sem.h for each arch using it, in prep to changeRich Felker2019-07-297-0/+112
|
* extricate bits/sem.h from x32 time_t hackRich Felker2019-07-297-25/+36
| | | | | | | | | | | | | | various padding fields in the generic bits/sem.h were defined in terms of time_t as a cheap hack standing in for "kernel long", to allow x32 to use the generic version of the file. this was a really bad idea, as it ended up getting copied into lots of arch-specific versions of the bits file, and is a blocker to changing time_t to 64-bit on 32-bit archs. this commit adds an x32-specific version of the header, and changes padding type back from time_t to long (currently the same type on all archs but x32) in the generic header and all the others the hack got copied into.
* remove trailing newlines from various versions of bits/shm.hRich Felker2019-07-299-9/+0
|
* remove duplicates of new generic bits/shm.hRich Felker2019-07-295-123/+0
|
* use 64-bit shmid_ds layout in the generic version of bits/shm.hRich Felker2019-07-291-3/+0
| | | | | | | | | this layout is more common already than the old generic, and should become even more common in the future with new archs added and with 64-bit time_t on 32-bit archs. the duplicate arch-specific copies are not removed yet in this commit, so as to assist git tooling in copy/rename tracking.
* duplicate generic bits/shm.h for each arch using it, in prep to changeRich Felker2019-07-295-0/+140
| | | | | | | | | | | | | there are more archs sharing the generic 64-bit version of the struct, which is uniform and much more reasonable, than sharing the current "generic" one, and depending on how time64 sysvipc is done for 32-bit archs, even more may be sharing the "64-bit version" in the future. so, duplicate the current generic to all archs using it (arm, i386, m68k, microblaze, or1k) so that the generic can be changed freely. this is recorded as its own commit mainly as a hint to git tooling, to assist in copy/move tracking.
* remove x32 syscall timespec fixup hacksRich Felker2019-07-291-58/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | the x32 syscall interfaces treat timespec's tv_nsec member as 64-bit despite the API type being long and long being 32-bit in the ABI. this is no problem for syscalls that store timespecs to userspace as results, but caused uninitialized padding to be misinterpreted as the high bits in syscalls that take timespecs as input. since the beginning of the port, we've dealt with this situation with hacks in syscall_arch.h, and injected between __syscall_cp_c and __syscall_cp_asm, to special-case the syscall numbers that involve timespecs as inputs and copy them to a form suitable to pass to the kernel. commit 40aa18d55ab763e69ad16d0cf1cebea708ffde47 set the stage for removal of these hacks by letting us treat the "normal" x32 syscalls dealing with timespec as if they're x32's "time64" syscalls, effectively making x32 ax "time64-only 32-bit arch" like riscv32 will be when it's added. since then, all users of syscalls that x32's syscall_arch.h had hacks for have been updated to use time64 syscalls, so the hacks can be removed. there are still at least a few other timespec-related syscalls broken on x32, which were overlooked when the x32 hacks were done or added later. these include at least recvmmsg, adjtimex/clock_adjtime, and timerfd_settime, and they will be fixed independently later on.
* internally, define time64 syscalls on x32 as the existing syscallsRich Felker2019-07-271-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | x32 is odd in that it's the only ILP32 arch/ABI we have where time_t is 64-bit rather than (32-bit) long, and this has always been problematic in that it results in struct timespec having unused padding space, since tv_nsec has type long, which the kernel insists be zero- or sign-extended (due to negative tv_nsec being invalid, it doesn't matter which) to match the x86_64 type. up til now, we've had really ugly hacks in x32/syscall_arch.h to patch up the timespecs passed to the kernel. but the same requirement to zero- or sign-extend tv_nsec also applies to all the new time64 syscalls on true 32-bit archs. so let's take advantage of this to clean things up. this patch defines all of the time64 syscalls for x32 as aliases for the existing syscalls by the same name. this establishes the following invariants: - if the time64 form is defined, it takes time arguments as 64-bit objects, and tv_nsec inputs must be zero-/sign-extended to 64-bit. - if the time64 form is not defined, or if the time64 form is defined and is not equal to the "plain" form, the plain form takes time arguments as longs. this will avoid the need for protocols for archs to define appropriate types for each family of syscalls, and for the reader of the code to have to be aware of such type definitions. in some sense it might be simpler if the plain syscall form were undefined for x32, so that it would always take longs if defined. however, a number of these syscalls are used in contexts with a null time argument, or (e.g. futex) for commands that don't involve time at all, and having to introduce time64-specific logic to all those call points does not make sense. thus, while the "plain" forms are kept now just because they're needed until the affected code is converted over, they'll also almost surely be kept in the future as well.
* don't use futimesat syscall as utimensat fallback on x32Rich Felker2019-07-271-0/+2
| | | | | | | | | | kernel support for x32 was added long after the utimensat syscall was already available, so having a fallback is just wasted code size. also, for changes related to time64 support on 32-bit archs, I want to be able to assume the old futimesat syscall always works with longs, which is true except for x32. by ensuring that it's not used on x32, the needed invariant is established.
* remove mips/n32/64 stat struct hacks from syscall machineryRich Felker2019-07-186-213/+36
| | | | | | now that we have a kstat structure decoupled from the public struct stat, we can just use the broken kernel structures directly and let the code in fstatat do the translation.
* decouple struct stat from kernel typeRich Felker2019-07-1816-0/+337
| | | | | | | | | | | | | | | presently, all archs/ABIs have struct stat matching the kernel stat[64] type, except mips/mipsn32/mips64 which do conversion hacks in syscall_arch.h to work around bugs in the kernel type. this patch completely decouples them and adds a translation step to the success path of fstatat. at present, this is just a gratuitous copying, but it opens up multiple possibilities for future support for 64-bit time_t on 32-bit archs and for cleaned-up/unified ABIs. for clarity, the mips hacks are not yet removed in this commit, so the mips kstat structs still correspond to the output of the hacks in their syscall_arch.h files, not the raw kernel type. a subsequent commit will fix this.
* remove utterly wrong includes from mips64/n32 bits/stat.hRich Felker2019-07-182-6/+0
| | | | | | | | these were overlooked during review. bits headers are not allowed to pull in additional headers (note: that rule is currently broken in other places but just for endian.h). string.h has no place here anyway, and including bits/alltypes.h without defining macros to request types from it is a nop.
* use register constraint instead of memory operand for riscv64 atomicsRich Felker2019-07-171-8/+8
| | | | | | | | the "A" constraint is simply for an address expression that's a single register, but it's not yet supported by clang, and has no advantage here over just using a register operand for the address. the latter is actually preferable in the a_cas_p case because it avoids aliasing an lvalue onto the memory.
* fix riscv64 atomic asm constraintsRich Felker2019-07-171-6/+10
| | | | | | | most egregious problem was the lack of memory clobber and lack of volatile asm; this made the atomics memory barriers but not compiler barriers. use of "+r" rather than "=r" for a clobbered temp was also wrong, since the initial value is indeterminate.
* fix riscv64 syscall asm constraintRich Felker2019-07-171-1/+1
| | | | | | | having "+r"(a0) is redundant with "0"(a0) in syscalls with at least 1 arg, which is arguably a constraint violation (clang treats it as such), and an invalid input with indeterminate value in the 0-arg case. use the "=r"(a0) form instead.
* clean up mips64/n32 syscall asm constraintsRich Felker2019-07-162-54/+56
| | | | | | | | | | | | | | | | | ever since inline syscalls were added for (o32) mips in commit 328810d32524e4928fec50b57e37e1bf330b2e40, the asm has nonsensically loaded the syscall number, rather than taking $2 as an input constraint to let the compiler load it. commit cfc09b1ecf0c6981494fd73dffe234416f66af10 improved on this somewhat by allowing a constant syscall number to propagate into an immediate, but missed that the whole operation made no sense. now, only $4, $5, $6, $8, and $9 are potential input-only registers. $2 is always input and output, and $7 is both when it's an argument, otherwise output-only. previously, $7 was treated as an input (with a "1" constraint matching its output position) even when it was not an input, which was arguably undefined behavior (asm input from indeterminate value). this is corrected.
* deduplicate mips64/n32 syscall clobbered register listsRich Felker2019-07-162-28/+22
| | | | | | | | | | | | | | this patch is not purely non-functional changes, since before, $8 and $9 were wrongly in the clobberlist for syscalls with fewer than 5 or 6 arguments. of course it's impossible for syscalls to have different clobbers depending on their number of arguments. the clobberlist for the recently-added 5- and 6-argument forms was correct, and for the 0- to 4-argument forms was erroneously copied from the mips o32 ABI where the additional arguments had to be passed on the stack. in making this change, I reviewed the kernel sources, and $8 and $9 are always saved for 64-bit kernels since they're part of the syscall argument list for n32 and n64 ABIs.
* fix build failure on arm building C code in thumb1 modeRich Felker2019-07-151-1/+1
| | | | | | | | | | | | a fully thumb1 build is not supported because some asm files are incompatible with thumb1, but apparently it works to compile the C code as thumb1 commit 06fbefd10046a0fae7e588b7c6d25fb51811b931 caused this regression but introducing use of the clz instruction, which is not supported in arm mode prior to v5, and not supported in thumb prior to thumb2 (v6t2). commit 1b9406b03c0a94ebe2076a8fc1746a8c45e78a83 fixed the issue only for arm mode pre-v5 but left thumb1 broken.
* fix conflicting mips and powerpc definitions for TIOCSER_TEMT macroSamuel Holland2019-07-105-5/+5
| | | | | | | | Commit 3517d74a5e04a377192d1f4882ad6c8dc22ce69a changed the token in sys/ioctl.h from 0x01 to 1, so bits/termios.h no longer matches. Revert the bits/termios.h change to keep the headers in sync. This reverts commit 9eda4dc69c33852c97c6f69176bf45ffc80b522f.
* remove spurious MAP_32BIT definition from riscv64 archRich Felker2019-07-041-1/+0
| | | | | | this was apparently copied from x86_64; it's not part of the kernel API for riscv64. this change eliminates the need for a riscv64-specific bits header and lets it use the generic one.
* add new syscall numbers from linux v5.1Szabolcs Nagy2019-07-0115-0/+327
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | syscall numbers are now synced up across targets (starting from 403 the numbers are the same on all targets other than an arch specific offset) IPC syscalls sem*, shm*, msg* got added where they were missing (except for semop: only semtimedop got added), the new semctl, shmctl, msgctl imply IPC_64, see linux commit 0d6040d4681735dfc47565de288525de405a5c99 arch: add split IPC system calls where needed new 64bit time_t syscall variants got added on 32bit targets, see linux commit 48166e6ea47d23984f0b481ca199250e1ce0730a y2038: add 64-bit time_t syscalls to all 32-bit architectures new async io syscalls got added, see linux commit 2b188cc1bb857a9d4701ae59aa7768b5124e262e Add io_uring IO interface linux commit edafccee56ff31678a091ddb7219aba9b28bc3cb io_uring: add support for pre-mapped user IO buffers a new syscall got added that uses the fd of /proc/<pid> as a stable handle for processes: allows sending signals without pid reuse issues, intended to eventually replace rt_sigqueueinfo, kill, tgkill and rt_tgsigqueueinfo, see linux commit 3eb39f47934f9d5a3027fe00d906a45fe3a15fad signal: add pidfd_send_signal() syscall on some targets (arm, m68k, s390x, sh) some previously missing syscall numbers got added as well.
* mips64: fix syscall numbers of io_pgetevents and rseqSzabolcs Nagy2019-07-011-2/+2
| | | | | | | | | the numbers added in commit d149e69c02eb558114f20ea718810e95538a3b2f add io_pgetevents and rseq syscall numbers from linux v4.18 were incorrect.
* s390x: drop SO_ definitions from bits/socket.hSzabolcs Nagy2019-07-011-28/+0
| | | | the s390x definitions matched the generic ones in sys/socket.h.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-11 09:09:14 +0000