powerpc: step-jump-cont failure (Was: [PATCH] utrace: don't set ->ops = utrace_detached_ops lockless)

[Ananth N Mavinakayanahalli]

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