Unnamed repository; edit this file 'description' to name the repository. http://euandre.org/git/grovel/atom?h=main 2016-01-22T03:50:58Z 2016-01-22T03:50:58Z Rich Felker dalias@aerifal.cx 2016-01-22T03:50:58Z urn:sha1:4de1bc1164ef40655caa148eeb50365112210561 commit f3ddd173806fd5c60b3f034528ca24542aecc5b9, the dynamic linker bootstrap overhaul, silently disabled the definition of __fpscr_values in this file since libc.so's copy of __fpscr_values now comes from crt_arch.h, the same place the public definition in the main program's crt1.o ultimately comes from. remove this file which is no longer in use. 2016-01-22T03:50:08Z Rich Felker dalias@aerifal.cx 2016-01-22T03:50:08Z urn:sha1:007907a93c4d26b579da25c81b43d74115a29016 2016-01-22T03:46:00Z Rich Felker dalias@aerifal.cx 2016-01-22T03:46:00Z urn:sha1:230bfe1a7d46c85601e5e67497cc607e15d08990 2016-01-21T19:43:04Z Rich Felker dalias@aerifal.cx 2016-01-21T19:28:15Z urn:sha1:61b1e75f7d8004461f2e18f171c26c2f545eed32 sh needs runtime-selected atomic backends since there are a number of supported models that use non-forwards-compatible (non-smp-compatible) atomic mechanisms. previously, the code paths for this were highly inefficient since they involved C function calls with multiple branches in the callee and heavy spills in the caller. the new code performs calls the runtime-selected asm fragment from inline asm with extremely minimal clobbers, rather than using a function call. for the sh4a case where the atomic mechanism is known and there is no forward-compatibility issue, the movli.l and movco.l instructions are provided as a_ll and a_sc, allowing the new shared atomic.h to generate efficient inline versions of all the basic atomic operations without needing a cas loop. 2015-09-22T04:10:42Z Rich Felker dalias@aerifal.cx 2015-09-22T04:10:42Z urn:sha1:cab2b1f9d71db31d6dc4ae9dcab6989182b7b533 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. 2015-09-12T02:55:28Z Rich Felker dalias@aerifal.cx 2015-09-12T02:55:28Z urn:sha1:234c58467c3709bafdd3ffa6ac73655e1dfd9ddb 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. 2015-06-16T14:55:06Z Rich Felker dalias@aerifal.cx 2015-06-16T14:55:06Z urn:sha1:3366a99b17847b58f2d8cc52cbb5d65deb824f8a 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. 2015-06-16T14:38:41Z Rich Felker dalias@aerifal.cx 2015-06-16T14:28:30Z urn:sha1:f9d84554bae0fa17c9a1d724549c4408022228a5 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. 2015-05-19T04:42:07Z Bobby Bingham koorogi@koorogi.info 2015-05-17T18:46:38Z urn:sha1:390f93ef69153bf2087fcf3baa1776ad9a6765ab 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. 2015-04-13T07:04:42Z Rich Felker dalias@aerifal.cx 2015-04-13T06:56:26Z urn:sha1:f3ddd173806fd5c60b3f034528ca24542aecc5b9 this overhaul further reduces the amount of arch-specific code needed by the dynamic linker and removes a number of assumptions, including: - that symbolic function references inside libc are bound at link time via the linker option -Bsymbolic-functions. - that libc functions used by the dynamic linker do not require access to data symbols. - that static/internal function calls and data accesses can be made without performing any relocations, or that arch-specific startup code handled any such relocations needed. removing these assumptions paves the way for allowing libc.so itself to be built with stack protector (among other things), and is achieved by a three-stage bootstrap process: 1. relative relocations are processed with a flat function. 2. symbolic relocations are processed with no external calls/data. 3. main program and dependency libs are processed with a fully-functional libc/ldso. reduction in arch-specific code is achived through the following: - crt_arch.h, used for generating crt1.o, now provides the entry point for the dynamic linker too. - asm is no longer responsible for skipping the beginning of argv[] when ldso is invoked as a command. - the functionality previously provided by __reloc_self for heavily GOT-dependent RISC archs is now the arch-agnostic stage-1. - arch-specific relocation type codes are mapped directly as macros rather than via an inline translation function/switch statement.