1. 21 8月, 2009 5 次提交
    • M
      sh: Fix bug calculating the end of the FDE instructions · 5480675d
      Matt Fleming 提交于
      The 'end' member of struct dwarf_fde denotes one byte past the end of
      the CFA instruction stream for an FDE. The value of 'end' was being
      calcualted incorrectly, it was being set too high. This resulted in
      dwarf_cfa_execute_insns() interpreting data past the end of valid
      instructions, thus causing all sorts of weird crashes.
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      5480675d
    • M
      sh: Setup the frame pointer in handle_interrupt · fe98dd31
      Matt Fleming 提交于
      When CONFIG_DWARF_UNWINDER is enabled setup r14 in handle_interrupt, so
      that we can figure out what function was running when we were
      interrupted.
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      fe98dd31
    • M
      sh: unwinder: Introduce UNWINDER_BUG() and UNWINDER_BUG_ON() · b344e24a
      Matt Fleming 提交于
      We can't assume that if we execute the unwinder code and the unwinder
      was already running that it has faulted. Clearly two kernel threads can
      invoke the unwinder at the same time and may be running simultaneously.
      
      The previous approach used BUG() and BUG_ON() in the unwinder code to
      detect whether the unwinder was incapable of unwinding the stack, and
      that the next available unwinder should be used instead. A better
      approach is to explicitly invoke a trap handler to switch unwinders when
      the current unwinder cannot continue.
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      b344e24a
    • M
      sh: unwinder: Set the flags for DW_CFA_val_offset ops as DWARF_VAL_OFFSET · 97efbbd5
      Matt Fleming 提交于
      The handling of DW_CFA_val_offset ops was incorrectly using the
      DWARF_REG_OFFSET flag but the register's value cannot be calculated
      using the DWARF_REG_OFFSET method. Create a new flag to indicate that a
      different method must be used to calculate the register's value even
      though there is no implementation for DWARF_VAL_OFFSET yet; it's mainly
      just a place holder.
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      97efbbd5
    • M
      sh: unwinder: Fix memory leak and create our own kmem cache · fb3f3e7f
      Matt Fleming 提交于
      Plug a memory leak in dwarf_unwinder_dump() where we didn't free the
      memory that we had previously allocated for the DWARF frames and DWARF
      registers.
      
      Now is also a opportune time to implement our own mempool and kmem
      cache. It's a good idea to have a certain number of frame and register
      objects in reserve at all times, so that we are guaranteed to have our
      allocation satisfied even when memory is scarce. Since we have pools to
      allocate from we can implement the registers for each frame as a linked
      list as opposed to a sparsely populated array. Whilst it's true that the
      lookup time for a linked list is larger than for arrays, there's only
      usually a maximum of 8 registers per frame. So the overhead isn't that
      much of a concern.
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      fb3f3e7f
  2. 17 8月, 2009 1 次提交
  3. 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
  4. 15 8月, 2009 11 次提交
  5. 14 8月, 2009 18 次提交
  6. 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