From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Mark Davis <markdavisinboston@gmail.com>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
linux-perf-users@vger.kernel.org
Subject: Re: No source code for static library (compiled with -g -ggdb)
Date: Fri, 29 Apr 2016 11:45:29 -0300 [thread overview]
Message-ID: <20160429144529.GI3386@kernel.org> (raw)
In-Reply-To: <CAPe7T+_UbFVFWpfcM8VrGQ_yXKcMcK1CDMVrPKZ4NY5ac-VyCA@mail.gmail.com>
Em Fri, Apr 29, 2016 at 08:28:29AM -0400, Mark Davis escreveu:
> Arnaldo, that's a really nice feature. Unfortunately, I'm currently
> running on an older version of perf (3.13.11-ckt18) and it's a bit of
> a pain to modify things like this on the cluster I'm running on
> (although I can if I have something I absolutely need). So, for me
Well, its not _that_ difficult to use a newer perf tool on whatever
kernel you are using, and that should work, as the new tool should
notice whatever features may be missing for something you ask it to do.
So, you can do:
[acme@jouet linux]$ make help | grep perf
perf-tar-src-pkg - Build perf-4.6.0-rc4.tar source tarball
perf-targz-src-pkg - Build perf-4.6.0-rc4.tar.gz source tarball
perf-tarbz2-src-pkg - Build perf-4.6.0-rc4.tar.bz2 source tarball
perf-tarxz-src-pkg - Build perf-4.6.0-rc4.tar.xz source tarball
[acme@jouet linux]$
Do any of this, say:
make perf-targz-src-pkg
On a recent kernel source, and you'll get a tarball with what you need
to build it on the target system.
Then just use it as ./perf or make sure that the binary is in your path.
> when I run verbose mode I simply get the DSO names in the callchains,
> but no arrows. I would assume, if I had a newer version of perf, that
> I would get no arrows for the symbols I want to annotate, given the
> behavior I'm seeing.
Yes, this seems to be the case.
> Anything else I can try? Does anyone have any ideas about why this may
> be happening? Again, this is only happening for symbols in my static
> library, and I'm creating this library using:
I'll read the other message you sent, I think you clarified things
further there...
> ar -cvrs $@ $(OBJS)
>
> (I'm not an expert on ar, so I could be doing this wrong?)
>
> On Thu, Apr 28, 2016 at 6:16 PM, Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
> > 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-29 14:45 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
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 [this message]
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=20160429144529.GI3386@kernel.org \
--to=acme@kernel.org \
--cc=arnaldo.melo@gmail.com \
--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).