1. 08 7月, 2010 1 次提交
  2. 07 4月, 2010 1 次提交
  3. 13 3月, 2010 1 次提交
    • C
      ptrace: move user_enable_single_step & co prototypes to linux/ptrace.h · dacbe41f
      Christoph Hellwig 提交于
      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: NChristoph Hellwig <hch@lst.de>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Roland McGrath <roland@redhat.com>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dacbe41f
  4. 17 2月, 2010 1 次提交
    • D
      powerpc: Extended ptrace interface · 3162d92d
      Dave Kleikamp 提交于
      powerpc: Extended ptrace interface
      
      From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
      
      Based on patches originally written by Torez Smith.
      
      Add a new extended ptrace interface so that user-space has a single
      interface for powerpc, without having to know the specific layout
      of the debug registers.
      
      Implement:
      PPC_PTRACE_GETHWDEBUGINFO
      PPC_PTRACE_SETHWDEBUG
      PPC_PTRACE_DELHWDEBUG
      Signed-off-by: NDave Kleikamp <shaggy@linux.vnet.ibm.com>
      Acked-by: NDavid Gibson <dwg@au1.ibm.com>
      Cc: Torez Smith  <lnxtorez@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      Cc: Sergio Durigan Junior <sergiodj@br.ibm.com>
      Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>
      Cc: linuxppc-dev list <Linuxppc-dev@ozlabs.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3162d92d
  5. 16 12月, 2009 1 次提交
  6. 09 6月, 2009 1 次提交
  7. 01 12月, 2008 1 次提交
  8. 21 10月, 2008 1 次提交
  9. 04 8月, 2008 1 次提交
  10. 28 7月, 2008 1 次提交
  11. 01 7月, 2008 1 次提交
    • M
      powerpc: Add VSX context save/restore, ptrace and signal support · ce48b210
      Michael Neuling 提交于
      This patch extends the floating point save and restore code to use the
      VSX load/stores when VSX is available.  This will make FP context
      save/restore marginally slower on FP only code, when VSX is available,
      as it has to load/store 128bits rather than just 64bits.
      
      Mixing FP, VMX and VSX code will get constant architected state.
      
      The signals interface is extended to enable access to VSR 0-31
      doubleword 1 after discussions with tool chain maintainers.  Backward
      compatibility is maintained.
      
      The ptrace interface is also extended to allow access to VSR 0-31 full
      registers.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      ce48b210
  12. 14 5月, 2008 1 次提交
  13. 18 4月, 2008 1 次提交
  14. 07 2月, 2008 1 次提交
  15. 30 1月, 2008 1 次提交
  16. 24 12月, 2007 1 次提交
  17. 14 6月, 2007 2 次提交
    • B
      [POWERPC] Uninline common ptrace bits · 865418d8
      Benjamin Herrenschmidt 提交于
      This folds back the ptrace-common.h bits back into ptrace.c and removes
      that file. The FSL SPE bits from ptrace-ppc32.h are folded back in as
      well.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      865418d8
    • B
      [POWERPC] ptrace updates & new, better requests · e17666ba
      Benjamin Herrenschmidt 提交于
      The powerpc ptrace interface is dodgy at best. We have defined our
      "own" versions of GETREGS/SETREGS/GETFPREGS/SETFPREGS that strangely
      take arguments in reverse order from other archs (in addition to having
      different request numbers) and have subtle issue, like not accessing
      all of the registers in their respective categories.
      
      This patch moves the implementation of those to a separate function
      in order to facilitate their deprecation in the future, and provides
      new ptrace requests that mirror the x86 and sparc ones and use the
      same numbers:
      
         PTRACE_GETREGS    : returns an entire pt_regs (the whole thing,
                             not only the 32 GPRs, though that doesn't
                             include the FPRs etc... There's a compat version
                             for 32 bits that returns a 32 bits compatible
                             pt_regs (44 uints)
      
         PTRACE_SETREGS    : sets an entire pt_regs (the whole thing,
                             not only the 32 GPRs, though that doesn't
                             include the FPRs etc... Some registers cannot be
                             written to and will just be dropped, this is the
                             same as with POKEUSR, that is anything above MQ
                             on 32 bits and CCR on 64 bits. There is a compat
                             version as well.
      
         PTRACE_GETFPREGS  : returns all the FP registers -including- the FPSCR
                             that is 33 doubles (regardless of 32/64 bits)
      
         PTRACE_SETFPREGS  : sets all the FP registers -including- the FPSCR
                             that is 33 doubles (regardless of 32/64 bits)
      
      And two that only exist on 64 bits kernels:
      
         PTRACE_GETREGS64  : Same as PTRACE_GETREGS, except there is no compat
                             function, a 32 bits process will obtain the full 64
                             bits registers
      
         PTRACE_SETREGS64  : Same as PTRACE_SETREGS, except there is no compat
                             function, a 32 bits process will set the full 64
                             bits registers
      
      The two later ones makes things easier to have a 32 bits debugger on a
      64 bits program (or on a 32 bits program that uses the full 64 bits of
      the GPRs, which is possible though has issues that will be fixed in a
      later patch).
      
      Finally, while at it, the patch removes a whole bunch of code duplication
      between ptrace32.c and ptrace.c, in large part by having the former call
      into the later for all requests that don't need any special "compat"
      treatment.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e17666ba
  18. 02 10月, 2006 1 次提交
  19. 22 9月, 2006 1 次提交
  20. 09 6月, 2006 1 次提交
  21. 09 1月, 2006 1 次提交
    • D
      [PATCH] syscall entry/exit revamp · 401d1f02
      David Woodhouse 提交于
      This cleanup patch speeds up the null syscall path on ppc64 by about 3%,
      and brings the ppc32 and ppc64 code slightly closer together.
      
      The ppc64 code was checking current_thread_info()->flags twice in the
      syscall exit path; once for TIF_SYSCALL_T_OR_A before disabling
      interrupts, and then again for TIF_SIGPENDING|TIF_NEED_RESCHED etc after
      disabling interrupts. Now we do the same as ppc32 -- check the flags
      only once in the fast path, and re-enable interrupts if necessary in the
      ptrace case.
      
      The patch abolishes the 'syscall_noerror' member of struct thread_info
      and replaces it with a TIF_NOERROR bit in the flags, which is handled in
      the slow path. This shortens the syscall entry code, which no longer
      needs to clear syscall_noerror.
      
      The patch adds a TIF_SAVE_NVGPRS flag which causes the syscall exit slow
      path to save the non-volatile GPRs into a signal frame. This removes the
      need for the assembly wrappers around sys_sigsuspend(),
      sys_rt_sigsuspend(), et al which existed solely to save those registers
      in advance. It also means I don't have to add new wrappers for ppoll()
      and pselect(), which is what I was supposed to be doing when I got
      distracted into this...
      
      Finally, it unifies the ppc64 and ppc32 methods of handling syscall exit
      directly into a signal handler (as required by sigsuspend et al) by
      introducing a TIF_RESTOREALL flag which causes _all_ the registers to be
      reloaded from the pt_regs by taking the ret_from_exception path, instead
      of the normal syscall exit path which stomps on the callee-saved GPRs.
      
      It appears to pass an LTP test run on ppc64, and passes basic testing on
      ppc32 too. Brief tests of ptrace functionality with strace and gdb also
      appear OK. I wouldn't send it to Linus for 2.6.15 just yet though :)
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      401d1f02
  22. 03 11月, 2005 1 次提交
  23. 12 9月, 2005 2 次提交
    • A
      [PATCH] ppc64: Add definitions for new PTRACE calls · a94d3085
      Anton Blanchard 提交于
      - Add PTRACE_GET_DEBUGREG/PTRACE_SET_DEBUGREG. The definition is
        as follows:
      
      /*
       * Get or set a debug register. The first 16 are DABR registers and the
       * second 16 are IABR registers.
       */
      #define PTRACE_GET_DEBUGREG    25
      #define PTRACE_SET_DEBUGREG    26
      
        DABR == data breakpoint and IABR = instruction breakpoint in IBM
        speak. We could split out the IABR into 2 more ptrace calls but I
        figured there was no need and 16 DABR registers should be more
        than enough (POWER4/POWER5 have one).
      
      - Add 2 new SIGTRAP si_codes: TRAP_HWBKPT and TRAP_BRANCH. I couldnt
        find any standards on either of these so I copied what ia64 is
        doing. Again this might be better placed in
        include/asm-generic/siginfo.h
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a94d3085
    • A
      [PATCH] ppc64: ptrace cleanups · a0987224
      Anton Blanchard 提交于
      - Remove the PPC_REG* defines
      - Wrap some more stuff with ifdef __KERNEL__
      - Add missing PT_TRAP, PT_DAR, PT_DSISR defines
      - Add PTRACE_GETEVRREGS/PTRACE_SETEVRREGS, even though we dont use it on
        ppc64 we dont want to allocate them for something else.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a0987224
  24. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4