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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).