1. 30 3月, 2011 1 次提交
    • D
      perf symbols: Properly align symbol_conf.priv_size · 4d439517
      David S. Miller 提交于
      If symbol_conf.priv_size is not a multiple of "sizeof(u64)" we'll bus
      error on sparc64 in symbol__new because the "struct symbol *" pointer
      is computed by adding symbol_conf.priv_size to the memory allocated.
      
      We cannot isolate the fix to symbol__new and symbol__delete since the
      private area is computed by subtracting the priv_size value from a
      "struct symbol" pointer, so then the private area can still be
      potentially unaligned.
      
      So, simply align the symbol_conf.priv_size value in symbol__init()
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <20110328.175849.112593455.davem@davemloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4d439517
  2. 29 3月, 2011 2 次提交
    • I
    • A
      perf symbols: Fix vsyscall symbol lookup · 6c6804fb
      Andrew Lutomirski 提交于
      Perf can't currently trace into the vsyscall page.  It looks like it was
      meant to work.
      
      Tested on 2.6.38 and today's -git.
      
      The bug is easy to reproduce.  Compile this:
      
      int main()
      {
      	int i;
      	struct timespec t;
      	for(i = 0; i < 10000000; i++)
      		clock_gettime(CLOCK_MONOTONIC, &t);
      	return 0;
      }
      
      and run it through perf record; perf report.  The top entry shows
      "[unknown]" and you can't zoom in.
      
      It looks like there are two issues.  The first is a that a test for user
      mode executing in kernel space is backwards.  (That's the first hunk
      below).  The second (I think) is that something's wrong with the code
      that generates lots of little struct dso objects for different sections
      -- when it runs on vmlinux it results in bogus long_name values which
      cause objdump to fail.
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LPU-Reference: <AANLkTikxSw5+wJZUWNz++nL7mgivCh_Zf=2Kq6=f9Ce_@mail.gmail.com>
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6c6804fb
  3. 28 3月, 2011 19 次提交
  4. 27 3月, 2011 18 次提交