lkml.org 
[lkml]   [2015]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC/PATCH] perf tools: Introduce perf_thread for backtrace
    On Fri, Nov 20, 2015 at 03:03:03PM +0900, Namhyung Kim wrote:
    > Backtrace is a crucial info for debugging. And upcoming refcnt
    > tracking facility also wants to use it.
    >
    > So instead of relying on glibc's backtrace_symbols[_fd] which misses
    > some (static) functions , use our own symbol searching mechanism. To
    > do that, add perf_thread global variable to keep its maps and symbols.
    >
    > The backtrace output from TUI is changed like below. (I made a key
    > action to generate a segfault for testing):
    >
    > Before:
    > perf: Segmentation fault
    > -------- backtrace --------
    > perf[0x544a8b]
    > /usr/lib/libc.so.6(+0x33680)[0x7fc46420b680]
    > perf[0x54041b]
    > perf(perf_evlist__tui_browse_hists+0x91)[0x5432e1]
    > perf(cmd_report+0x1d20)[0x43cb10]
    > perf[0x487073]
    > perf(main+0x62f)[0x42cb1f]
    > /usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fc4641f8610]
    > perf(_start+0x29)[0x42cc39]
    > [0x0]
    >
    > After:
    > perf: Segmentation fault
    > -------- backtrace --------
    > perf_evsel__hists_browse(+0x43b) in perf [0x54066b]
    > perf_evlist__tui_browse_hists(+0x91) in perf [0x543531]
    > cmd_report(+0x1d20) in perf [0x43cb50]
    > run_builtin(+0x53) in perf [0x4870b3]
    > main(+0x634) in perf [0x42cb54]
    > __libc_start_main(+0xf0) in libc-2.22.so [0x7fea3577c610]
    > _start(+0x29) in perf [0x42cc79]
    > [0x0]

    nice idea!

    SNIP

    > +
    > +void create_perf_thread(void)
    > +{
    > + struct perf_tool tool = {
    > + .comm = perf_event__process_comm,
    > + .mmap = perf_event__process_mmap,
    > + .mmap2 = perf_event__process_mmap2,
    > + };
    > + struct thread_map *tm;
    > + struct machine *machine;
    > + int pid = getpid();
    > +
    > + machine = machine__new_host();
    > + if (machine == NULL)
    > + return;
    > +
    > + tm = thread_map__new_dummy();
    > + if (tm == NULL) {
    > + machine__delete(machine);
    > + return;
    > + }

    I think we could treat errors the usual way in here..
    if fail to alloc this early, something is terribly wrong anyway

    jirka


    \
     
     \ /
      Last update: 2015-11-20 11:01    [W:4.436 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site