From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Mark Davis <markdavisinboston@gmail.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: No source code for static library (compiled with -g -ggdb)
Date: Thu, 28 Apr 2016 19:16:53 -0300 [thread overview]
Message-ID: <20160428221653.GD3386@kernel.org> (raw)
In-Reply-To: <CAPe7T+8oQptK0Wak2y_b1RNBy7ddmftc+++HNMPF5R8BDxWVYQ@mail.gmail.com>
Em Thu, Apr 28, 2016 at 01:44:16PM -0400, Mark Davis escreveu:
> Hello, I'm using perf record and perf report to profile an application
> which is made from a static (.a) library file that I made as well as a
> handful of C++ files that are not in the static library. They are all
> compiled with "-g -ggdb -fno-inline -O2 -fno-omit-frame-pointer" and
> all linked together to create the application.
>
> When I use perf report (in interactive/tui mode), when I annotate the
> symbols that are in the C++ files (not the static library), I see the
> source code intermingled with the assembly (this is what I want). I
> can do this at any layer of the call stack. However, when I drill into
> the symbols that are from the static library, I just see the assembly
> of the leaf symbol. I don't expect to see the source in this case, as
> the leaf symbol is a low-level library from libc; but, perf report
> won't let me drill into (i.e., annotate) any non-leaf symbols.
>
> Example:
> execute_native_thread_routine
> std::_Bind_simple<int (*(int, char**, Thread*))(int, char**,
> Thread*)>::operator()()
> main(int, char**)
> my_func_A
> my_func_B
> malloc
What happens when you press 'V'? Here, say for this callchain:
- 0.73% gnome-shell libgobject-2.0.so.0.4600.2 [.] handlers_find
- handlers_find
- 0.68% signal_handlers_foreach_matched_R
g_signal_handlers_disconnect_matched
0x7f71fe809a80
g_object_unref
- st_widget_get_theme_node
0.58% 0x7f71fe813429
And I press V, I get:
- 0.73% gnome-shell libgobject-2.0.so.0.4600.2 [.] handlers_find
-→handlers_find libgobject-2.0.so.0.4600.2
- 0.68% signal_handlers_foreach_matched_R libgobject-2.0.so.0.4600.2
g_signal_handlers_disconnect_matched libgobject-2.0.so.0.4600.2
0x7f71fe809a80 libgnome-shell.so
→g_object_unref libgobject-2.0.so.0.4600.2
-→st_widget_get_theme_node libgnome-shell.so
0.58% 0x7f71fe813429 libgnome-shell.so
See those arrows? They point to the places where you can annotate, the others
can't because they had no samples or were unresolved.
With some changes I think we can show the ones without samples, but that remains to be done.
Also, this is with:
[root@jouet ~]# perf --version
perf version 4.6.rc4.ga453697
This feature was introduced in:
commit 70e972788888315851a5c1b4982efbcafcd03b5b
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Thu Mar 19 16:07:21 2015 -0300
perf hists browser: Indicate which callchain entries are annotated
Now that we can annotate entries in a callchain, show which ones have an
associated symbol and samples, by adding a right arrow just before the
symbol name when in verbose mode.
To toggle verbose mode press 'V'.
---------------------------------
Which is:
[acme@jouet linux]$ git tag --contains 70e972788888315851a5c1b4982efbcafcd03b5b | grep ^v4 | head -1
v4.1
[acme@jouet linux]$
Thanks,
- Arnaldo
> When I annotate my_func_A and my_func_B, it just jumps to the
> annotation of malloc (I see this listed at the top of the annotation
> view). Note that my_func_A and my_func_B are both defined in the
> static library that I'm linking in. However, when I do a similar thing
> with a different stack where I'm annotating a function that's not from
> the static library (but in the regular C++ files), it works fine.
>
> Here's what I'm doing to create my static lib:
> ar -cvrs $@ $(OBJS)
>
>
> I did confirm with nm --debug-syms that my static lib has debugging
> symbols in it:
>
> U __assert_fail
> 0000000000000000 b .bss
> 0000000000000000 n .comment
> U __cxa_atexit
> 0000000000000000 d .data
> 0000000000000000 N .debug_abbrev
> 0000000000000000 N .debug_aranges
> 0000000000000000 N .debug_info
> 0000000000000000 N .debug_line
> 0000000000000000 N .debug_loc
> 0000000000000000 N .debug_ranges
> 0000000000000000 N .debug_str
> U __dso_handle
> 0000000000000000 r .eh_frame
> U exit
>
>
> How can I compile and link my application and configure perf report so
> I can drill in like this on functions defined in a static library with
> debug symbols?
>
> Thank you,
> Mark
> --
> To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-04-28 22:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 17:44 No source code for static library (compiled with -g -ggdb) Mark Davis
2016-04-28 22:16 ` Arnaldo Carvalho de Melo [this message]
2016-04-29 12:28 ` Mark Davis
2016-04-29 13:26 ` Mark Davis
2016-05-02 7:58 ` Milian Wolff
2016-08-16 20:14 ` Mark Davis
2016-04-29 14:45 ` Arnaldo Carvalho de Melo
2016-04-30 23:49 ` Mark Davis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160428221653.GD3386@kernel.org \
--to=acme@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=markdavisinboston@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.