about summary refs log tree commit diff
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
...
* fix dynamic linker path file selection for arm vs armhfRich Felker2016-01-201-3/+3
| | | | | | | | | | the __SOFTFP__ macro which was wrongly being used does not reflect the ABI (arm vs armhf) but just the availability of floating point instructions/registers, so -mfloat-abi=softfp was wrongly being treated as armhf. __ARM_PCS_VFP is the correct predefined macro to check for the armhf EABI variant. this macro usage was corrected for the build process in commit 4918c2bb206bfaaf5a1f7d3448c2f63d5e2b7d56 but reloc.h was apparently overlooked at the time.
* adjust mips crt_arch entry point asm to avoid assembler bugsRich Felker2015-12-291-1/+4
| | | | | | | | | | | | | apparently the .gpword directive does not work reliably with local text labels; values produced were offset by 64k from the correct value, resulting in incorrect computation of the got pointer at runtime. instead, use an external label so that the assembler does not munge the relocation; the linker will then get it right. commit 6fef8cafbd0f6f185897bc87feb1ff66e2e204e1 exposed this issue by removing the old, non-PIE-compatible handwritten crt1.s, which was not affected. presumably mips PIE executables (using Scrt1.o produced from crt_arch.h) were already affected at the time.
* adjust i386 max_align_t definition to work around some broken compilersRich Felker2015-12-291-3/+5
| | | | | | | | | | at least gcc 4.7 claims c++11 support but does not accept the alignas keyword, causing breakage when stddef.h is included in c++11 mode. instead, prefer using __attribute__((__aligned__)) on any compiler with GNU extensions, and only use the alignas keyword as a fallback for other C++ compilers. C code should not be affected by this patch.
* remove visibility suppression by SHARED macro in mips and x32 arch filesRich Felker2015-12-152-6/+0
| | | | | | commit 8a8fdf6398b85c99dffb237e47fa577e2ddc9e77 was intended to remove all such usage, but these arch-specific files were overlooked, leading to inconsistent declarations and definitions.
* fix dynamic loader library mapping for nommu systemsRich Felker2015-11-111-0/+2
| | | | | | | | | | | | | | | | | | | | | on linux/nommu, non-writable private mappings of files may actually use memory shared with other processes or the fs cache. the old nommu loader code (used when mmap with MAP_FIXED fails) simply wrote over top of the original file mapping, possibly clobbering this shared memory. no such breakage was observed in practice, but it should have been possible. the new code starts by mapping anonymous writable memory on archs that might support nommu, then maps load segments over top of it, falling back to read if MAP_FIXED fails. we use an anonymous map rather than a writable file map to avoid reading more data from disk than needed. since pages cannot be loaded lazily on fault, in case of large data/bss, mapping the full file may read a lot of data that will subsequently be thrown away when processing additional LOAD segments. as a result, we cannot skip the first LOAD segment when operating in this mode. these changes affect only non-FDPIC nommu support.
* explicitly assemble all arm asm sources as UALRich Felker2015-11-101-0/+1
| | | | | | | | these files are all accepted as legacy arm syntax when producing arm code, but legacy syntax cannot be used for producing thumb2 with access to the full ISA. even after switching to UAL, some asm source files contain instructions which are not valid in thumb mode, so these will need to be addressed separately.
* remove non-working pre-armv4t support from arm asmRich Felker2015-11-092-11/+0
| | | | | | | | | | | | | | | the idea of the three-instruction sequence being removed was to be able to return to thumb code when used on armv4t+ from a thumb caller, but also to be able to run on armv4 without the bx instruction available (in which case the low bit of lr would always be 0). however, without compiler support for generating such a sequence from C code, which does not exist and which there is unlikely to be interest in implementing, there is little point in having it in the asm, and it would likely be easier to add pre-armv4t support via enhanced linker handling of R_ARM_V4BX than at the compiler level. removing this code simplifies adding support for building libc in thumb2-only form (for cortex-m).
* generalize sh entry point asm not to assume call dests fit in 12 bitsRich Felker2015-11-021-5/+12
| | | | | | 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.
* properly access mcontext_t program counter in cancellation handlerRich Felker2015-11-0210-12/+10
| | | | | | | | | 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.
* prevent reordering of or1k and powerpc thread pointer loadsRich Felker2015-10-152-0/+2
| | | | | | | | | | | | | | | | | 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.
* mark arm thread-pointer-loading inline asm as volatileRich Felker2015-10-151-3/+3
| | | | | | | | | | 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.
* add comment documenting hard-coded opcode for reading mips thread pointerRich Felker2015-10-151-0/+1
|
* remove attribute((const)) from arm __pthread_self inline functionRich Felker2015-10-151-2/+2
| | | | | commit a603a75a72bb469c6be4963ed1b55fabe675fe15 did this for the public pthread_self function but not the internal inline one.
* fix signal return for sh/fdpicRich Felker2015-09-232-0/+10
| | | | | | | | | | | | | | | | the restorer function pointer provided in the kernel sigaction structure is interpreted by the kernel as a raw code address, not a function descriptor. this commit moves the declarations of the __restore and __restore_rt symbols to ksigaction.h so that arch versions of the file can override them, and introduces a version for sh which declares them as objects rather than functions. an alternate solution would have been defining SA_RESTORER to 0 so that the functions are not used, but this both requires executable stack (since the sh kernel does not have a vdso page with permanent restorer functions) and crashes on qemu user-level emulation.
* have sh/fdpic entry point set fdpic personality if neededRich Felker2015-09-221-0/+12
| | | | | | | | | | | | | | | | | the entry point code supports being loaded by a loader which is not fdpic-aware (in practice, either kernel with mmu or qemu without fdpic support). this mostly just works, but signal handling will wrongly use a function descriptor address as a code address if the personality is not adjusted to fdpic. ideally this code could be placed with sigaction so that it's not needed except if/when a signal handler is installed. however, personality is incorrectly maintained per-thread by the kernel, rather than per-process, so it's necessary to correct the personality before any threads are started. also, in order to skip the personality syscall when an fdpic-aware loader is used, we need to be able to detect how the program was loaded, and this information is only readily available at the entry point.
* add real fdpic loading of shared librariesRich Felker2015-09-221-0/+1
| | | | | | previously, the normal ELF library loading code was used even for fdpic, so only the kernel-loaded dynamic linker and main app could benefit from separate placement of segments and shared text.
* size-optimize sh/fdpic dynamic entry pointRich Felker2015-09-221-0/+4
| | | | | | the __fdpic_fixup code is not needed for ET_DYN executables, which instead use reloctions, so we can omit it from the dynamic linker and static-pie entry point and save some code size.
* work around breakage in sh/fdpic __unmapself functionRich Felker2015-09-221-0/+5
| | | | | | | | | | | | the C implementation of __unmapself used for potentially-nommu sh assumed CRTJMP takes a function descriptor rather than a code address; however, the actual dynamic linker needs a code address, and so commit 7a9669e977e5f750cf72ccbd2614f8b72ce02c4c changed the definition of the macro in reloc.h. this commit puts the old macro back in a place where it only affects __unmapself. this is an ugly workaround and should be cleaned up at some point, but at least it's well isolated.
* add general fdpic support in dynamic linker and arch support for shRich Felker2015-09-222-3/+12
| | | | | | | | | | | | | | | | | | at this point not all functionality is complete. the dynamic linker itself, and main app if it is also loaded by the kernel, take advantage of fdpic and do not need constant displacement between segments, but additional libraries loaded by the dynamic linker follow normal ELF semantics for mapping still. this fully works, but does not admit shared text on nommu. in terms of actual functional correctness, dlsym's results are presently incorrect for function symbols, RTLD_NEXT fails to identify the caller correctly, and dladdr fails almost entirely. with the dynamic linker entry point working, support for static pie is automatically included, but linking the main application as ET_DYN (pie) probably does not make sense for fdpic anyway. ET_EXEC is equally relocatable but more efficient at representing relocations.
* new dlstart stage-2 chaining for x86_64 and x32Rich Felker2015-09-172-0/+10
|
* new dlstart stage-2 chaining for powerpcRich Felker2015-09-171-0/+9
|
* new dlstart stage-2 chaining for or1kRich Felker2015-09-171-0/+9
|
* new dlstart stage-2 chaining for mipsRich Felker2015-09-171-0/+15
|
* new dlstart stage-2 chaining for microblazeRich Felker2015-09-171-0/+7
|
* introduce new symbol-lookup-free rcrt1/dlstart stage chainingRich Felker2015-09-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | previously, the call into stage 2 was made by looking up the symbol name "__dls2" (which was chosen short to be easy to look up) from the dynamic symbol table. this was no problem for the dynamic linker, since it always exports all its symbols. in the case of the static pie entry point, however, the dynamic symbol table does not contain the necessary symbol unless -rdynamic/-E was used when linking. this linking requirement is a major obstacle both to practical use of static-pie as a nommu binary format (since it greatly enlarges the file) and to upstream toolchain support for static-pie (adding -E to default linking specs is not reasonable). this patch replaces the runtime symbolic lookup with a link-time lookup via an inline asm fragment, which reloc.h is responsible for providing. in this initial commit, the asm is provided only for i386, and the old lookup code is left in place as a fallback for archs that have not yet transitioned. modifying crt_arch.h to pass the stage-2 function pointer as an argument was considered as an alternative, but such an approach would not be compatible with fdpic, where it's impossible to compute function pointers without already having performed relocations. it was also deemed desirable to keep crt_arch.h as simple/minimal as possible. in principle, archs with pc-relative or got-relative addressing of static variables could instead load the stage-2 function pointer from a static volatile object. that does not work for fdpic, and is not safe against reordering on mips-like archs that use got slots even for static functions, but it's a valid on i386 and many others, and could provide a reasonable default implementation in the future.
* reindent powerpc's bits/termios.h to be consistent with other archsFelix Janda2015-09-151-140/+138
|
* fix namespace violations in aarch64/bits/termios.hFelix Janda2015-09-151-7/+7
| | | | in analogy with commit a627eb35864d5c29a3c3300dfe83745ab1e7a00f
* add sh fdpic subarch variantsRich Felker2015-09-121-1/+16
| | | | | | | | | with this commit it should be possible to produce a working static-linked fdpic libc and application binaries for sh. the changes in reloc.h are largely unused at this point since dynamic linking is not supported, but the CRTJMP macro is used one place outside of dynamic linking, in __unmapself.
* add fdpic version of entry point code for shRich Felker2015-09-121-0/+29
| | | | | | | this version of the entry point is only suitable for static linking in ET_EXEC form. neither dynamic linking nor pie is supported yet. at some point in the future the fdpic and non-fdpic versions of this code may be unified but for now it's easiest to work with them separately.
* make sh clone asm fdpic-compatibleRich Felker2015-09-121-0/+5
| | | | | | | | | | | clone calls back to a function pointer provided by the caller, which will actually be a pointer to a function descriptor on fdpic. the obvious solution is to have a separate version of clone for fdpic, but I have taken a simpler approach to go around the problem. instead of calling the pointed-to function from asm, a direct call is made to an internal C function which then calls the pointed-to function. this lets the C compiler generate the appropriate calling convention for an indirect call with no need for ABI-specific assembly.
* fix missing earlyclobber flag in i386 a_ctz_64 asmRich Felker2015-09-091-1/+1
| | | | | | | | | this error was only found by reading the code, but it seems to have been causing gcc to produce wrong code in malloc: the same register was used for the output and the high word of the input. in principle this could have caused an infinite loop searching for an available bin, but in practice most x86 models seem to implement the "undefined" result of the bsf instruction as "unchanged".
* implement arm eabi mem* functionsTimo Teräs2015-08-314-0/+36
| | | | | | | these functions are part of the ARM EABI, meaning compilers may generate references to them. known versions of gcc do not use them, but llvm does. they are not provided by libgcc, and the de facto standard seems to be that libc provides them.
* mitigate performance regression in libc-internal locks on x86_64Rich Felker2015-08-162-2/+2
| | | | | | | | | commit 3c43c0761e1725fd5f89a9c028cbf43250abb913 fixed missing synchronization in the atomic store operation for i386 and x86_64, but opted to use mfence for the barrier on x86_64 where it's always available. however, in practice mfence is significantly slower than the barrier approach used on i386 (a nop-like lock orl operation). this commit changes x86_64 (and x32) to use the faster barrier.
* aarch64: fix 64-bit syscall argument passingSzabolcs Nagy2015-08-111-4/+2
| | | | | | | | | On 32bit systems long long arguments are passed in a special way to some syscalls; this accidentally got copied to the AArch64 port. The following interfaces were broken: fallocate, fanotify, ftruncate, posix_fadvise, posix_fallocate, pread, pwrite, readahead, sync_file_range, truncate.
* fix missing synchronization in atomic store on i386 and x86_64Rich Felker2015-07-283-3/+3
| | | | | | | | | | | | | | | | | despite being strongly ordered, the x86 memory model does not preclude reordering of loads across earlier stores. while a plain store suffices as a release barrier, we actually need a full barrier, since users of a_store subsequently load a waiter count to determine whether to issue a futex wait, and using a stale count will result in soft (fail-to-wake) deadlocks. these deadlocks were observed in malloc and possible with stdio locks and other libc-internal locking. on i386, an atomic operation on the caller's stack is used as the barrier rather than performing the store itself using xchg; this avoids the need to read the cache line on which the store is being performed. mfence is used on x86_64 where it's always available, and could be used on i386 with the appropriate cpu model checks if it's shown to perform better.
* socket.h: cleanup/reorder mips and powerpc bits/socket.hRoman Yeryomin2015-07-212-18/+20
| | | | | | ....to be somewhat consistent and easily comparable with asm/socket.h Signed-off-by: Roman Yeryomin <roman@ubnt.com>
* socket.h: fix SO_* for mipsRoman Yeryomin2015-07-212-1/+6
| | | | Signed-off-by: Roman Yeryomin <roman@ubnt.com>
* mips: fix mcontext_t register array field nameFelix Fietkau2015-07-211-1/+1
| | | | | | glibc and uclibc use gregs instead of regs Signed-off-by: Felix Fietkau <nbd@openwrt.org>
* fix local-dynamic model TLS on mips and powerpcRich Felker2015-06-252-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | the TLS ABI spec for mips, powerpc, and some other (presently unsupported) RISC archs has the return value of __tls_get_addr offset by +0x8000 and the result of DTPOFF relocations offset by -0x8000. I had previously assumed this part of the ABI was actually just an implementation detail, since the adjustments cancel out. however, when the local dynamic model is used for accessing TLS that's known to be in the same DSO, either of the following may happen: 1. the -0x8000 offset may already be applied to the argument structure passed to __tls_get_addr at ld time, without any opportunity for runtime relocations. 2. __tls_get_addr may be used with a zero offset argument to obtain a base address for the module's TLS, to which the caller then applies immediate offsets for individual objects accessed using the local dynamic model. since the immediate offsets have the -0x8000 adjustment applied to them, the base address they use needs to include the +0x8000 offset. it would be possible, but more complex, to store the pointers in the dtv[] array with the +0x8000 offset pre-applied, to avoid the runtime cost of adding 0x8000 on each call to __tls_get_addr. this change could be made later if measurements show that it would help.
* switch to using trap number 31 for syscalls on shRich Felker2015-06-161-1/+1
| | | | | | | | | | | | | | | | | | | nominally the low bits of the trap number on sh are the number of syscall arguments, but they have never been used by the kernel, and some code making syscalls does not even know the number of arguments and needs to pass an arbitrary high number anyway. sh3/sh4 traditionally used the trap range 16-31 for syscalls, but part of this range overlapped with hardware exceptions/interrupts on sh2 hardware, so an incompatible range 32-47 was chosen for sh2. using trap number 31 everywhere, since it's in the existing sh3/sh4 range and does not conflict with sh2 hardware, is a proposed unification of the kernel syscall convention that will allow binaries to be shared between sh2 and sh3/sh4. if this is not accepted into the kernel, we can refit the sh2 target with runtime selection mechanisms for the trap number, but doing so would be invasive and would entail non-trivial overhead.
* switch sh port's __unmapself to generic version when running on sh2/nommuRich Felker2015-06-161-0/+19
| | | | | | | | | | | | | due to the way the interrupt and syscall trap mechanism works, userspace on sh2 must never set the stack pointer to an invalid value. thus, the approach used on most archs, where __unmapself executes with no stack for the interval between SYS_munmap and SYS_exit, is not viable on sh2. in order not to pessimize sh3/sh4, the sh asm version of __unmapself is not removed. instead it's renamed and redirected through code that calls either the generic (safe) __unmapself or the sh3/sh4 asm, depending on compile-time and run-time conditions.
* add support for sh2 interrupt-masking-based atomics to sh portRich Felker2015-06-163-8/+113
| | | | | | | | | | | | | | | | | | | the sh2 target is being considered an ISA subset of sh3/sh4, in the sense that binaries built for sh2 are intended to be usable on later cpu models/kernels with mmu support. so rather than hard-coding sh2-specific atomics, the runtime atomic selection mechanisms that was already in place has been extended to add sh2 atomics. at this time, the sh2 atomics are not SMP-compatible; since the ISA lacks actual atomic operations, the new code instead masks interrupts for the duration of the atomic operation, producing an atomic result on single-core. this is only possible because the kernel/hardware does not impose protections against userspace doing so. additional changes will be needed to support future SMP systems. care has been taken to avoid producing significant additional code size in the case where it's known at compile-time that the target is not sh2 and does not need sh2-specific code.
* arm: add vdso supportSzabolcs Nagy2015-06-141-0/+4
| | | | | vdso will be available on arm in linux v4.2, the user-space code for it is in kernel commit 8512287a8165592466cb9cb347ba94892e9c56a5
* fix stack alignment code in mips crt_arch.hRich Felker2015-05-241-2/+2
| | | | | | | | | | | | | | the instruction used to align the stack, "and $sp, $sp, -8", does not actually exist; it's expanded to 2 instructions using the 'at' (assembler temporary) register, and thus cannot be used in a branch delay slot. since alignment mod 16 commutes with subtracting 8, simply swapping these two operations fixes the problem. crt1.o was not affected because it's still being generated from a dedicated asm source file. dlstart.lo was not affected because the stack pointer it receives is already aligned by the kernel. but Scrt1.o was affected in cases where the dynamic linker gave it a misaligned stack pointer.
* add .text section directive to all crt_arch.h files missing itRich Felker2015-05-227-0/+7
| | | | | | | | i386 and x86_64 versions already had the .text directive; other archs did not. normally, top-level (file scope) __asm__ starts in the .text section anyway, but problems were reported with some versions of clang, and it seems preferable to set it explicitly anyway, at least for the sake of consistency between archs.
* fix inconsistency in a_and and a_or argument types on x86[_64]Rich Felker2015-05-203-12/+12
| | | | | | conceptually, and on other archs, these functions take a pointer to int, but in the i386, x86_64, and x32 versions of atomic.h, they took a pointer to void instead.
* inline llsc atomics when building for sh4aBobby Bingham2015-05-192-90/+128
| | | | | | | If we're building for sh4a, the compiler is already free to use instructions only available on sh4a, so we can do the same and inline the llsc atomics. If we're building for an older processor, we still do the same runtime atomics selection as before.
* make arm reloc.h CRTJMP macro compatible with thumbRich Felker2015-05-141-0/+5
| | | | | | | | | | | | | compilers targeting armv7 may be configured to produce thumb2 code instead of arm code by default, and in the future we may wish to support targets where only the thumb instruction set is available. the instructions this patch omits in thumb mode are needed only for non-thumb versions of armv4 or earlier, which are not supported by any current compilers/toolchains and thus rather pointless to have. at some point these compatibility return sequences may be removed from all asm source files, and in that case it would make sense to remove them here too and remove the ifdef.
* make arm crt_arch.h compatible with thumb code generationRich Felker2015-05-141-4/+6
| | | | | | | | | | | | | | | | | | compilers targeting armv7 may be configured to produce thumb2 code instead of arm code by default, and in the future we may wish to support targets where only the thumb instruction set is available. the changes made here avoid operating directly on the sp register, which is not possible in thumb code, and address an issue with the way the address of _DYNAMIC is computed. previously, the relative address of _DYNAMIC was stored with an additional offset of -8 versus the pc-relative add instruction, since on arm the pc register evaluates to ".+8". in thumb code, it instead evaluates to ".+4". both are two (normal-size) instructions beyond "." in the current execution mode, so the numbered label 2 used in the relative address expression is simply moved two instructions ahead to be compatible with both instruction sets.
* fix stack protector crashes on x32 & powerpc due to misplaced TLS canaryRich Felker2015-05-062-0/+3
| | | | | | | | | | | | | | | | | | | i386, x86_64, x32, and powerpc all use TLS for stack protector canary values in the default stack protector ABI, but the location only matched the ABI on i386 and x86_64. on x32, the expected location for the canary contained the tid, thus producing spurious mismatches (resulting in process termination) upon fork. on powerpc, the expected location contained the stdio_locks list head, so returning from a function after calling flockfile produced spurious mismatches. in both cases, the random canary was not present, and a predictable value was used instead, making the stack protector hardening much less effective than it should be. in the current fix, the thread structure has been expanded to have canary fields at all three possible locations, and archs that use a non-default location must define a macro in pthread_arch.h to choose which location is used. for most archs (which lack TLS canary ABI) the choice does not matter.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-11 19:55:52 +0000