On Wed, Aug 10, 2005 at 10:33:50AM +0200, Martin Schwidefsky wrote: > Christoph Hellwig <[EMAIL PROTECTED]> wrote on 08/10/2005 10:00:57 AM: > > > The sys_ptrace boilerplate code (everything outside the big switch > > statement for the arch-specific requests) is shared by most > > architectures. This patch moves it to kernel/ptrace.c and leaves the > > arch-specific code as arch_ptrace. > > > > Some architectures have a too different ptrace so we have to exclude > > them: alpha, ia64, m32r, parisc, sparc, sparc64. They continue to > > keep their implementations. For sh64 I had to add a sh64_ptrace wrapper > > because it does some initialization on the first call. For um I removed > > an ifdefed SUBARCH_PTRACE_SPECIAL block, but SUBARCH_PTRACE_SPECIAL > > isn't defined anywhere in the tree. > > There is one small problem with the new ptrace code for s390. We have > this horribly broken ptrace hack to get the ieee instruction pointer > of the last fpu exception. The fpu itself doesn't store the value so > the exception handler of the kernel stores the instruction pointer to > the thread structure. A process is allowed to ptrace itself (!) with the > peek/poke value of PT_IEEE_IP to get this value. This is used in the > fpu code in glibc. I know this is broken but I can't help it. Without > this hack existing glibc code will fall over. > > To make this work the special case needs to be dealt with before the > ptrace_check_attach check is done. My suggestion would be to move the > ptrace_check_attach to the arch_ptrace function. Then the s390 specific > arch_ptrace function could insert the PT_IEEE_IP check before calling > ptrace_chek_attach. The only other alternative is a s390 copy of > sys_ptrace.
I suspect at this point it's better to leave s390 out of the consolidation. I'll have another patch that'll make the implementations that aren't consolidated use the new ptrace_get_task_struct function, so there will be far less code duplicated than now.
