From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
Randy Dunlap <rdunlap@xenotime.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Naren A Devaiah <naren.devaiah@in.ibm.com>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Oleg Nesterov <oleg@redhat.com>, Mark Wielaard <mjw@redhat.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
LKML <linux-kernel@vger.kernel.org>,
Jim Keniston <jkenisto@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCHv9 2.6.35-rc4-tip 0/13] Uprobes Patches:
Date: Wed, 21 Jul 2010 18:49:53 +0530 [thread overview]
Message-ID: <20100721131953.GA4290@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100720210358.GA17631@ghostprotocols.net>
* Arnaldo Carvalho de Melo <acme@infradead.org> [2010-07-20 18:03:59]:
> Em Tue, Jul 20, 2010 at 12:08:05PM +0530, Srikar Dronamraju escreveu:
> > > A minor note on perf probe -S output: This seems to include a lot of
> > > T.456 or similar labels, which from my recollection are gcc internal
> > > things. It would be good to filter those out as they aren't quite
> > > useful and just fill up the list.
> >
> > Okay .. will take a look. Offhand I dont know about the T.456
> > labels, so I will google and see if its possible for us to identify if
> > its a t.456 label. However if you know how to identify a t456 label
> > from normal functions, then it would be great.
>
> We may have some hint on the symtab, having access to one of those files
> to look at its symtab will help.
Based on inputs from Christoph and Arnaldo and Steven, I was trying to see
what could be filtered out from the current listing.
For example current listing of libc would list labels like these
(I think Christoph is refering to these as t.456 labels).
(Thankfully Steven Rostedt also confirms this).
.L2
.L3
.L4
.L5
.L6
.L7
.L8
.L9
(Think we should exclude these labels from listing.)
However I now see more classifications and I am not sure if all of these
classifications should be included. I am giving 8 listings each for each
classification.
stty GLOBAL binding DEFAULT visibility
swab GLOBAL binding DEFAULT visibility
sync GLOBAL binding DEFAULT visibility
time GLOBAL binding DEFAULT visibility
verr GLOBAL binding DEFAULT visibility
warn GLOBAL binding DEFAULT visibility
abort GLOBAL binding DEFAULT visibility
alarm GLOBAL binding DEFAULT visibility
(Think we should include the above in listing.)
fini LOCAL binding DEFAULT visibility
init LOCAL binding DEFAULT visibility
pcmp LOCAL binding DEFAULT visibility
__brk LOCAL binding DEFAULT visibility
comma LOCAL binding DEFAULT visibility
do_in LOCAL binding DEFAULT visibility
__dup LOCAL binding DEFAULT visibility
_help LOCAL binding DEFAULT visibility
_itoa LOCAL binding DEFAULT visibility
token LOCAL binding DEFAULT visibility
(I am not sure if the above should be included in listing. This type of
classification seem to be present in libc only. However I might be wrong
here.)
_init LOCAL binding HIDDEN visibility
_fitoa LOCAL binding HIDDEN visibility
__GI_ffs LOCAL binding HIDDEN visibility
__utimes LOCAL binding HIDDEN visibility
__futimes LOCAL binding HIDDEN visibility
__GI_exit LOCAL binding HIDDEN visibility
__GI_glob LOCAL binding HIDDEN visibility
__GI_time LOCAL binding HIDDEN visibility
__GI_verr LOCAL binding HIDDEN visibility
__GI_warn LOCAL binding HIDDEN visibility
__readall LOCAL binding HIDDEN visibility
(Guess functions listed under this classification shouldnt be listed.
Again I have seen this classification only in libc.)
brk WEAK binding DEFAULT visibility
dup WEAK binding DEFAULT visibility
bcmp WEAK binding DEFAULT visibility
dup2 WEAK binding DEFAULT visibility
feof WEAK binding DEFAULT visibility
ffsl WEAK binding DEFAULT visibility
fork WEAK binding DEFAULT visibility
getc WEAK binding DEFAULT visibility
gets WEAK binding DEFAULT visibility
kill WEAK binding DEFAULT visibility
(I see this classification in both libraries and executables. Generally
these are plt enteries. Again I am not sure if these enteries need to be
part of listing. In some of the DSO, these enteries have a symbol value of
0. i.e if somebody requests to probe a weak symbol in a particular dso, then
chances are we fail to probe because we dont get the right address.)
The other way to look at it is seeing how fork and malloc are categorized.
__fork GLOBAL binding DEFAULT visibility
__vfork GLOBAL binding DEFAULT visibility
__libc_fork GLOBAL binding DEFAULT visibility
__register_atfork GLOBAL binding DEFAULT visibility
free_atfork LOCAL binding DEFAULT visibility
__GI___vfork LOCAL binding DEFAULT visibility
malloc_atfork LOCAL binding DEFAULT visibility
__GI___fork LOCAL binding HIDDEN visibility
__unregister_atfork LOCAL binding HIDDEN visibility
__GI___register_atfork LOCAL binding HIDDEN visibility
fork WEAK binding DEFAULT visibility
vfork WEAK binding DEFAULT visibility
malloc GLOBAL binding DEFAULT visibility
__libc_malloc GLOBAL binding DEFAULT visibility
__malloc LOCAL binding DEFAULT visibility
mallochook LOCAL binding DEFAULT visibility
_int_malloc LOCAL binding DEFAULT visibility
malloc_check LOCAL binding DEFAULT visibility
malloc_atfork LOCAL binding DEFAULT visibility
__malloc_trim LOCAL binding DEFAULT visibility
ptmalloc_init LOCAL binding DEFAULT visibility
tr_mallochook LOCAL binding DEFAULT visibility
__malloc_stats LOCAL binding DEFAULT visibility
malloc_hook_ini LOCAL binding DEFAULT visibility
ptmalloc_lock_all LOCAL binding DEFAULT visibility
malloc_consolidate LOCAL binding DEFAULT visibility
__malloc_get_state LOCAL binding DEFAULT visibility
__malloc_set_state LOCAL binding DEFAULT visibility
__malloc_check_init LOCAL binding DEFAULT visibility
ptmalloc_unlock_all LOCAL binding DEFAULT visibility
__malloc_usable_size LOCAL binding DEFAULT visibility
ptmalloc_unlock_all2 LOCAL binding DEFAULT visibility
__GI___libc_malloc LOCAL binding HIDDEN visibility
malloc_trim WEAK binding DEFAULT visibility
malloc_stats WEAK binding DEFAULT visibility
malloc_get_state WEAK binding DEFAULT visibility
malloc_set_state WEAK binding DEFAULT visibility
malloc_usable_size WEAK binding DEFAULT visibility
I think we should just list the symbols under classification GLOBAL binding,
default visibility.
--
Thanks and Regards
Srikar
prev parent reply other threads:[~2010-07-21 13:20 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-12 10:32 [PATCHv9 2.6.35-rc4-tip 0/13] Uprobes Patches: Srikar Dronamraju
2010-07-12 10:32 ` [PATCHv9 2.6.35-rc4-tip 1/13] mm: Move replace_page() / write_protect_page() to mm/memory.c Srikar Dronamraju
2010-07-12 10:32 ` [PATCHv9 2.6.35-rc4-tip 2/13] uprobes: Breakpoint insertion/removal in user space applications Srikar Dronamraju
2010-07-20 4:28 ` Christoph Hellwig
2010-07-20 7:22 ` Srikar Dronamraju
2010-08-04 12:05 ` Peter Zijlstra
2010-08-04 12:48 ` Srikar Dronamraju
2010-08-04 13:02 ` Peter Zijlstra
2010-07-12 10:32 ` [PATCHv9 2.6.35-rc4-tip 3/13] uprobes: Slot allocation for Execution out of line(XOL) Srikar Dronamraju
2010-07-12 10:32 ` [PATCHv9 2.6.35-rc4-tip 4/13] uprobes: x86 specific functions for user space breakpointing Srikar Dronamraju
2010-07-12 10:33 ` [PATCHv9 2.6.35-rc4-tip 5/13] uprobes: Uprobes (un)registration and exception handling Srikar Dronamraju
2010-07-12 10:33 ` [PATCHv9 2.6.35-rc4-tip 6/13] uprobes: X86 support for Uprobes Srikar Dronamraju
2010-07-12 10:33 ` [PATCHv9 2.6.35-rc4-tip 7/13] uprobes: Uprobes Documentation Srikar Dronamraju
2010-07-12 10:33 ` [PATCHv9 2.6.35-rc4-tip 8/13] trace: Extract out common code for kprobes/uprobes traceevents Srikar Dronamraju
2010-07-12 10:34 ` [PATCHv9 2.6.35-rc4-tip 9/13] trace: uprobes trace_event interface Srikar Dronamraju
2010-07-12 10:34 ` [PATCHv9 2.6.35-rc4-tip 10/13] perf: Re-Add make_absolute_path Srikar Dronamraju
2010-07-12 14:00 ` Arnaldo Carvalho de Melo
2010-07-12 14:30 ` Steven Rostedt
2010-07-12 16:12 ` Arnaldo Carvalho de Melo
2010-07-14 2:49 ` Steven Rostedt
2010-07-14 16:23 ` Arnaldo Carvalho de Melo
2010-07-14 20:45 ` Ingo Molnar
2010-07-14 20:50 ` Mathieu Desnoyers
2010-07-12 15:33 ` Srikar Dronamraju
2010-07-12 16:26 ` Arnaldo Carvalho de Melo
2010-07-12 17:26 ` Srikar Dronamraju
2010-07-12 10:34 ` [PATCHv9 2.6.35-rc4-tip 11/13] perf: perf interface for uprobes Srikar Dronamraju
2010-07-12 16:03 ` Arnaldo Carvalho de Melo
2010-07-12 17:32 ` Srikar Dronamraju
2010-07-12 10:34 ` [PATCHv9 2.6.35-rc4-tip 12/13] [RFC] perf: Show Potential probe points Srikar Dronamraju
2010-07-12 14:41 ` Arnaldo Carvalho de Melo
2010-07-12 15:55 ` Srikar Dronamraju
2010-07-12 10:34 ` [PATCHv9 2.6.35-rc4-tip 13/13] [RFC] perf: show functions in a file without using pid Srikar Dronamraju
2010-07-20 4:19 ` [PATCHv9 2.6.35-rc4-tip 0/13] Uprobes Patches: Christoph Hellwig
2010-07-20 6:38 ` Srikar Dronamraju
2010-07-20 21:03 ` Arnaldo Carvalho de Melo
2010-07-21 2:42 ` Srikar Dronamraju
2010-07-21 13:08 ` Steven Rostedt
2010-07-21 13:21 ` Srikar Dronamraju
2010-07-21 13:26 ` Christoph Hellwig
2010-07-21 14:10 ` Steven Rostedt
2010-07-21 14:22 ` Arnaldo Carvalho de Melo
2010-07-21 15:50 ` Steven Rostedt
2010-07-21 13:19 ` Srikar Dronamraju [this message]
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=20100721131953.GA4290@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=acme@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=ananth@in.ibm.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=mjw@redhat.com \
--cc=naren.devaiah@in.ibm.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rdunlap@xenotime.net \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
/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.