On Mon, Dec 07, 2009 at 07:05:40PM +0100, Oleg Nesterov wrote: > On 12/07, Oleg Nesterov wrote: > > > > On 12/07, Jan Kratochvil wrote: > > > > > > On Mon, 07 Dec 2009 15:24:51 +0100, Oleg Nesterov wrote: > > > > But. &raise_sigusr2 is not equal to the "actual" address of > > > > &raise_sigusr2(), > > > > this value points to the "thunk" (I do not know the correct English > > > > term) > > > > > > ppc64 calls it "function descriptor" (GDB > > > ppc64_linux_convert_from_func_ptr_addr): > > > For PPC64, a function descriptor is a TOC entry, > > > > Thanks Jan. > > > > > in a data section, > > > > Yes! > > > > Now I can't understand how this test-case could ever work on ppc. > > step-jump-cont does: > > > > regs->nip = raise_sigusr2; <--- points to data section > > ptrace(PTRACE_CONT); > > > > of course, the tracee gets SIGSEGV, this section is not executable. > > Hmm. Looks like, "powerpc" means a lot of different hardware, and > _PAGE_EXEC may be 0. I didn't notice this when I quickly grepped > arch/powerpc/ > > IOW, perhaps on some machines r implies x ? > > Is yes, this can explain why the results differ on different > machines.
Well, powerpc 32-bit adheres to the SVR4 ABI, while powerpc 64-bit uses the PPC64-ELF ABI (http://refspecs.linuxfoundation.org/ELF/ppc64/). The 64bit ABI uses function descriptors and the 'func_name' is the data address, while the '.func_name' is the text address. (See handle_rt_signal64 in arch/powerpc/kernel/signal_64.c and kprobe_lookup_name in arch/powerpc/include/asm/kprobes.h. Ananth