On Fri, 30 Nov 2007, Brad Boyer wrote: > > * There are no spare registers available to designate as the thread > > register. Therefore, kernel magic is needed to obtain the thread > > pointer from userspace. Kernel helpers are provided in a vDSO since > > they will need unwind information associated; see details below. > > Compiler-generated code will use an ABI-defined function > > __m68k_read_tp with that function handling the details of calling > > the vDSO. > > Have you thought about where this pointer will be stored? A vDSO is > normally shared across all processes and has no thread specific data. > With it being abstracted out this way, it wouldn't need to be documented, > but I'm curious if you have any better ideas than just making it a > system call to read and write this value and store it in the thread > context structure.
With the ARM magic kernel page the pointer is stored at another location in that page - we decided against using a magic page with a fixed address as part of the interface on m68k/ColdFire, in favour of using a vDSO, because of unwinding and debugging problems associated with executing code in a magic page (whereas a vDSO acts more or less like another shared library from that point of view), but the kernel could choose to map another page per thread (at a fixed address but not one used directly except by the vDSO and not one used for any executable code) and keep the thread pointer in there. Or it could use a system call, though that would be slower. > > The helper __kernel_atomic_cmpxchg_32 compares the 32-bit value at the > > location pointed to by a0 with the value in d0. If the values are > > equal, it writes the value in d1 to the location pointed to by a0; > > otherwise, it writes the value at the location pointed to by a0 to d0. > > It does not clobber any registers other than the condition codes (and > > the modification of d0 indicated so that d0 is returned with the > > original value of the memory location in all cases). (On m68k - where > > this kernel helper would only be used if glibc is built for the > > intersection of ColdFire and m68k - this could be implemented with a > > single cas instruction and a return.) > > I presume ColdFire is also missing CAS2. Do we need a 64 bit cmpxchg > equivalent as well? No, 32-bit compare-and-exchange suffices for NPTL; it's the only one for which ARM has a kernel helper, and the others are set to cause NPTL to fail to link if they get used. (If a future version of NPTL starts to need more atomic operations, then we may need to add more kernel helpers at that point.) > > The helper __kernel_atomic_barrier provides a memory barrier. It does > > not clobber any registers other than the condition codes. On non-SMP, > > it can just return to the user; on SMP it needs to ensure memory > > synchronization between processors. > > Can you get SMP ColdFire boxes? Linux has historically not supported > SMP on m68k, and much of the code isn't really SMP safe (particularly > some of the drivers for 68k based systems). This isn't to say we > shouldn't have this option, but it seems like a low priority. I don't know if SMP exists at present, but the aim is that glibc binaries built now should work on any future SMP hardware and kernels, which seems to require a kernel barrier operation unless you know there will never be SMP hardware (or that such hardware will have a memory architecture not needing the barriers). -- Joseph S. Myers [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
