1. 18 8月, 2009 6 次提交
  2. 16 8月, 2009 3 次提交
    • M
      sh: Add support for DWARF GNU extensions · cd7246f0
      Matt Fleming 提交于
      Also, remove the "fix" to DW_CFA_def_cfa_register where we reset the
      frame's cfa_offset to 0. This action is incorrect when handling
      DW_CFA_def_cfa_register as the DWARF spec specifically states that the
      previous contents of cfa_offset should be used with the new
      register. The reason that I thought cfa_offset should be reset to 0 was
      because it was being assigned a bogus value prior to executing the
      DW_CFA_def_cfa_register op. It turns out that the bogus cfa_offset value
      came from interpreting .cfi_escape pseudo-ops (those used by the GNU
      extensions) as CFA_DW_def_cfa ops.
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      cd7246f0
    • M
      sh: Try again at getting the initial return address for an unwind · b955873b
      Matt Fleming 提交于
      The previous hack for calculating the return address for the first frame
      we unwind (dwarf_unwinder_dump) didn't always work. The problem was that
      it assumed once it read the rule for calculating the return address,
      there would be no new rules for calculating it. This isn't true because
      the way in which the CFA is calculated can change as you progress
      through a function and the return address is figured out using the
      CFA. Therefore, the way to calculate the return address can change.
      
      So, instead of using some offset from the beginning of
      dwarf_unwind_stack which is just a flakey approach, and instead of
      executing instructions from the FDE until the return address is setup,
      we now figure out the pc in dwarf_unwind_stack() just before we call
      dwarf_cfa_execute_insns().
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      b955873b
    • P
      sh: Merge the _32/_64 variants of arch/sh/kernel/Makefile. · 38f9ddf4
      Paul Mundt 提交于
      This uses the BITS export as per x86 in order to allow the same Makefile
      to be used.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      38f9ddf4
  3. 15 8月, 2009 11 次提交
  4. 14 8月, 2009 18 次提交
  5. 13 8月, 2009 2 次提交
    • P
      perf_counter: Report the cloning task as parent on perf_counter_fork() · 94d5d1b2
      Peter Zijlstra 提交于
      A bug in (9f498cc5: perf_counter: Full task tracing) makes
      profiling multi-threaded apps it go belly up.
      
      [ output as: (PID:TID):(PPID:PTID) ]
      
       # ./perf report -D | grep FORK
      0x4b0 [0x18]: PERF_EVENT_FORK: (3237:3237):(3236:3236)
      0xa10 [0x18]: PERF_EVENT_FORK: (3237:3238):(3236:3236)
      0xa70 [0x18]: PERF_EVENT_FORK: (3237:3239):(3236:3236)
      0xad0 [0x18]: PERF_EVENT_FORK: (3237:3240):(3236:3236)
      0xb18 [0x18]: PERF_EVENT_FORK: (3237:3241):(3236:3236)
      
      Shows us that the test (27d028de perf report: Update for the new
      FORK/EXIT events) in builtin-report.c:
      
              /*
               * A thread clone will have the same PID for both
               * parent and child.
               */
              if (thread == parent)
                      return 0;
      
      Will clearly fail.
      
      The problem is that perf_counter_fork() reports the actual
      parent, instead of the cloning thread.
      
      Fixing that (with the below patch), yields:
      
       # ./perf report -D | grep FORK
      0x4c8 [0x18]: PERF_EVENT_FORK: (1590:1590):(1589:1589)
      0xbd8 [0x18]: PERF_EVENT_FORK: (1590:1591):(1590:1590)
      0xc80 [0x18]: PERF_EVENT_FORK: (1590:1592):(1590:1590)
      0x3338 [0x18]: PERF_EVENT_FORK: (1590:1593):(1590:1590)
      0x66b0 [0x18]: PERF_EVENT_FORK: (1590:1594):(1590:1590)
      
      Which both makes more sense and doesn't confuse perf report
      anymore.
      Reported-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: paulus@samba.org
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      LKML-Reference: <1250172882.5241.62.camel@twins>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      94d5d1b2
    • P
      perf_counter: Fix an ipi-deadlock · 970892a9
      Peter Zijlstra 提交于
      perf_pending_counter() is called from IRQ context and will call
      perf_counter_disable(), however perf_counter_disable() uses
      smp_call_function_single() which doesn't fancy being used with
      IRQs disabled due to IPI deadlocks.
      
      Fix this by making it use the local __perf_counter_disable()
      call and teaching the counter_sched_out() code about pending
      disables as well.
      
      This should cover the case where a counter migrates before the
      pending queue gets processed.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Corey J Ashford <cjashfor@us.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: stephane eranian <eranian@googlemail.com>
      LKML-Reference: <20090813103655.244097721@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      970892a9