lwn.git/arch/frv/include/asm/ptrace.h, branch next

Merge tag 'disintegrate-misc-arches-20121010' of git://git.infradead.org/users/dhowells/linux-headers

2012-10-13T02:22:31+00:00

Pull UAPI disintegration for misc arches from David Howells: "UAPI disintegration for MN10300, FRV and AVR32 arches" * tag 'disintegrate-misc-arches-20121010' of git://git.infradead.org/users/dhowells/linux-headers: UAPI: (Scripted) Disintegrate arch/mn10300/include/asm UAPI: (Scripted) Disintegrate arch/frv/include/asm UAPI: (Scripted) Disintegrate arch/avr32/include/asm

UAPI: (Scripted) Disintegrate arch/frv/include/asm

2012-10-10T11:09:42+00:00

Signed-off-by: David Howells Acked-by: Arnd Bergmann Acked-by: Thomas Gleixner Acked-by: Michael Kerrisk Acked-by: Paul E. McKenney Acked-by: Dave Jones

frv: switch to generic sys_execve()

2012-10-01T04:53:10+00:00

current_pt_regs() here is simply __frame Acked-by: David Howells Signed-off-by: Al Viro

ptrace: unify show_regs() prototype

2011-07-26T23:49:43+00:00

[ poleg@redhat.com: no need to declare show_regs() in ptrace.h, sched.h does this ] Signed-off-by: Mike Frysinger Cc: Tejun Heo Signed-off-by: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

ptrace: move user_enable_single_step & co prototypes to linux/ptrace.h

2010-03-12T23:52:38+00:00

While in theory user_enable_single_step/user_disable_single_step/ user_enable_blockstep could also be provided as an inline or macro there's no good reason to do so, and having the prototype in one places keeps code size and confusion down. Roland said: The original thought there was that user_enable_single_step() et al might well be only an instruction or three on a sane machine (as if we have any of those!), and since there is only one call site inlining would be beneficial. But I agree that there is no strong reason to care about inlining it. As to the arch changes, there is only one thought I'd add to the record. It was always my thinking that for an arch where PTRACE_SINGLESTEP does text-modifying breakpoint insertion, user_enable_single_step() should not be provided. That is, arch_has_single_step()=>true means that there is an arch facility with "pure" semantics that does not have any unexpected side effects. Inserting a breakpoint might do very unexpected strange things in multi-threaded situations. Aside from that, it is a peculiar side effect that user_{enable,disable}_single_step() should cause COW de-sharing of text pages and so forth. For PTRACE_SINGLESTEP, all these peculiarities are the status quo ante for that arch, so having arch_ptrace() itself do those is one thing. But for building other things in the future, it is nicer to have a uniform "pure" semantics that arch-independent code can expect. OTOH, all such arch issues are really up to the arch maintainer. As of today, there is nothing but ptrace using user_enable_single_step() et al so it's a distinction without a practical difference. If/when there are other facilities that use user_enable_single_step() and might care, the affected arch's can revisit the question when someone cares about the quality of the arch support for said new facility. Signed-off-by: Christoph Hellwig Cc: Oleg Nesterov Cc: Roland McGrath Acked-by: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

FRV: Implement new-style ptrace

2009-06-11T16:01:26+00:00

Implement the new-style ptrace for FRV, including adding appropriate tracehooks. Signed-off-by: David Howells Signed-off-by: Linus Torvalds

FRV: Move to arch/frv/include/asm/

2009-04-10T00:48:06+00:00

Move arch headers from include/asm-frv/ to arch/frv/include/asm/. Signed-off-by: David Howells