1. 12 11月, 2009 1 次提交
  2. 11 11月, 2009 7 次提交
    • M
      perf tools: Test -fstack-protector-all compiler option for inclusion in CFLAGS · 5d7bdab7
      Michael Cree 提交于
      Some architectures (e.g. Alpha) do not support the
      -fstack-protector-all compiler option and the use of the option
      with -Werror causes the compiler to abort and the build fails.
      
      Test that the compiler supports -fstack-protector-all before
      inclusion in CFLAGS.
      Signed-off-by: NMichael Cree <mcree@orcon.net.nz>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <20091111074302.GA3728@omega>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5d7bdab7
    • F
      perf tools: Bring linear set of section headers for features · 9e827dd0
      Frederic Weisbecker 提交于
      Build a set of section headers for features right after the
      datas. Each implemented feature will have one of such section
      header that provides the offset and the size of the data
      manipulated by the feature.
      
      The trace informations have moved after the data and are
      recorded on exit time.
      
      The new layout is as follows:
      
       -----------------------
                                   ___
       [ magic               ]      |
       [ header size         ]      |
       [ attr size           ]      |
       [ attr content offset ]      |
       [ attr content size   ]      |
       [ data offset         ]  File Headers
       [ data size           ]      |
       [ event_types offset  ]      |
       [ event_types size    ]      |
       [ feature bitmap      ]      v
      
       [ attr section        ]
       [ events section      ]
      
                                   ___
       [         X           ]      |
       [         X           ]      |
       [         X           ]    Datas
       [         X           ]      |
       [         X           ]      v
      
                                   ___
       [ Feature 1 offset    ]      |
       [ Feature 1 size      ] Features headers
       [ Feature 2 offset    ]      |
       [ Feature 2 size      ]      v
      
       [ Feature 1 content   ]
       [ Feature 2 content   ]
       -----------------------
      
      We have as many feature's section headers as we have features in
      use for the current file.
      
      Say Feat 1 and Feat 3 are used by the file, but not Feat 2. Then
      the feature headers will be like follows:
      
      [ Feature 1 offset    ]      |
      [ Feature 1 size      ] Features headers
      [ Feature 3 offset    ]      |
      [ Feature 3 size      ]      v
      
      There is no hole to cover Feature 2 that is not in use here. We
      only need to cover the needed headers in order, from the lowest
      feature bit to the highest.
      
      Currently we have two features: HEADER_TRACE_INFO and
      HEADER_BUILD_ID. Both have their contents that follow the
      feature headers. Putting the contents right after the feature
      headers is not mandatory though. While we keep the feature
      headers right after the data and in order, their offsets can
      point everywhere. We have just put the two above feature
      contents in the end of the file for convenience.
      
      The purpose of this layout change is to have a file format that
      scales while keeping it simple: having such linear feature
      headers is less error prone wrt forward/backward compatibility
      as the content of a feature can be put anywhere, its location
      can even change by the time, it's fine because its headers will
      tell where it is. And we know how to find these headers,
      following the above rules.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      LKML-Reference: <1257911467-28276-6-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9e827dd0
    • F
      perf tools: Use perf_header__set/has_feat whenever possible · 3e13ab2d
      Frederic Weisbecker 提交于
      And drop the alternate checks/sets using set_bit or other kind
      of helpers.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      LKML-Reference: <1257911467-28276-5-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3e13ab2d
    • F
      perf tools: Read the build-ids from the header layer · 4778d2e4
      Frederic Weisbecker 提交于
      Keep the build-ids reading implementation in the data mapping
      but move its call to the headers so that we have a better
      control on it (offset seeking, size passing, etc..).
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      LKML-Reference: <1257911467-28276-4-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4778d2e4
    • F
      perf tools: Split up build id saving into fetch and write · 57f395a7
      Frederic Weisbecker 提交于
      We are saving the build id once we stop the profiling. And only
      after doing that we know if we need to set that feature in the
      header through the feature bitmap.
      
      But if we want a proper feature support in the headers, using a
      rule of offset/size pairs in sections, we need to know in
      advance how many features we need to set in the headers, so that
      we can reserve rooms for their section headers.
      
      The current state doesn't allow that, as it forces us to first
      save the build-ids to the file right after the datas instead of
      planning any structured layout.
      
      That's why this splits up the build-ids processing in two parts:
      one that fetches the build-ids from the Dso objects, and one
      that saves them into the file.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      LKML-Reference: <1257911467-28276-3-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      57f395a7
    • F
      perf tools: Move the build-id storage operations to headers · 8671dab9
      Frederic Weisbecker 提交于
      So that it makes easier to control it. Especially because we
      plan to give it a feature section.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      LKML-Reference: <1257911467-28276-2-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8671dab9
    • F
      perf tools: Synthetize the targeted process · de896721
      Frederic Weisbecker 提交于
      Don't forget to also synthetize the targeted process from perf
      record or we'll miss its dso in the events and then we won't be
      able to deal with its build-id.
      
      We are missing it because it is created after the existing
      synthetized tasks but before the counters are enabled and can
      send its mapping event.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      LKML-Reference: <1257911467-28276-1-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      de896721
  3. 09 11月, 2009 3 次提交
  4. 08 11月, 2009 1 次提交
    • A
      perf symbols: Use the buildids if present · 8d06367f
      Arnaldo Carvalho de Melo 提交于
      With this change 'perf record' will intercept PERF_RECORD_MMAP
      calls, creating a linked list of DSOs, then when the session
      finishes, it will traverse this list and read the buildids,
      stashing them at the end of the file and will set up a new
      feature bit in the header bitmask.
      
      'perf report' will then notice this feature and populate the
      'dsos' list and set the build ids.
      
      When reading the symtabs it will refuse to load from a file that
      doesn't have the same build id. This improves the
      reliability of the profiler output, as symbols and profiling
      data is more guaranteed to match.
      
      Example:
      
       [root@doppio ~]# perf report | head
       /home/acme/bin/perf with build id b1ea544ac3746e7538972548a09aadecc5753868 not found, continuing without symbols
        # Samples: 2621434559
        #
        # Overhead          Command                  Shared Object  Symbol
        # ........  ...............  .............................  ......
        #
             7.91%             init  [kernel]        [k] read_hpet
             7.64%             init  [kernel]        [k] mwait_idle_with_hints
             7.60%          swapper  [kernel]        [k] read_hpet
             7.60%          swapper  [kernel]        [k] mwait_idle_with_hints
             3.65%             init  [kernel]        [k] 0xffffffffa02339d9
      [root@doppio ~]#
      
      In this case the 'perf' binary was an older one, vanished,
      so its symbols probably wouldn't match or would cause subtly
      different (and misleading) output.
      
      Next patches will support the kernel as well, reading the build
      id notes for it and the modules from /sys.
      
      Another patch should also introduce a new plumbing command:
      
      'perf list-buildids'
      
      that will then be used in porcelain that is distro specific to
      fetch -debuginfo packages where such buildids are present. This
      will in turn allow for one to run 'perf record' in one machine
      and 'perf report' in another.
      
      Future work on having the buildid sent directly from the kernel
      in the PERF_RECORD_MMAP event is needed to close races, as the
      DSO can be changed during a 'perf record' session, but this
      patch at least helps with non-corner cases and current/older
      kernels.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: K. Prasad <prasad@linux.vnet.ibm.com>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      LKML-Reference: <1257367843-26224-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8d06367f
  5. 04 11月, 2009 9 次提交
  6. 03 11月, 2009 19 次提交