Prev: Removing dead ARCH_GUMSTIX_ORIG
Next: What's the relationship between Linux driver running priority and FIFO policy?
From: Steven Rostedt on 21 Jul 2010 09:10
On Wed, 2010-07-21 at 08:12 +0530, Srikar Dronamraju wrote:

> I tried searching for t.456 gcc labels in google. I dont think I found
> anything interesting. Are we looking at not listing symbols that end
> with @plt? Can you please list an example t.456 label. Also any pointers to
> where I can find more information on the same would be very useful.

I'm not sure you'll find anything looking for "t.456" since that is just
a random label that gcc created for its internal use. But I believe that
all of these temp labels have a '.' in them. Thus, you can just ignore
all labels with '.'.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 21 Jul 2010 09:30
On Wed, Jul 21, 2010 at 06:51:47PM +0530, Srikar Dronamraju wrote:
> Thanks a lot for confirming this. I did some digging and was thinking that may
> be .L<blah><blah> were the ones that Christoph was referring.

Well, for me it's T.<blah><blah>, but these seem to be either the same
or similar.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Srikar Dronamraju on 21 Jul 2010 09:30
* Arnaldo Carvalho de Melo <acme(a)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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Steven Rostedt on 21 Jul 2010 10:20
On Wed, 2010-07-21 at 09:26 -0400, Christoph Hellwig wrote:
> On Wed, Jul 21, 2010 at 06:51:47PM +0530, Srikar Dronamraju wrote:
> > Thanks a lot for confirming this. I did some digging and was thinking that may
> > be .L<blah><blah> were the ones that Christoph was referring.
>
> Well, for me it's T.<blah><blah>, but these seem to be either the same
> or similar.

I've seen both and more.


# nm vmlinux |grep '\.'
ffffffff824d0000 b .brk.dmi_alloc
ffffffff81602710 r ACPI_PSS_BIOS_BUG_MSG.30386
ffffffff81638340 r C.283.15204
ffffffff816382f0 r C.284.15205
ffffffff8164eab0 r C.415.26901
ffffffff81621530 r C.430.27428
ffffffff81606dc0 r C.519.31522
ffffffff81647e00 r C.541.33601
[...]
ffffffff81659590 r CSWTCH.952
ffffffff8135598c t T.1032
ffffffff81355955 t T.1034
ffffffff81051ffb t T.1065
ffffffff81335398 t T.1073

This dump does not have the .L labels, but I have seen them before.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 21 Jul 2010 10:30
Em Wed, Jul 21, 2010 at 08:12:00AM +0530, Srikar Dronamraju escreveu:
> > 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.
>
> I tried searching for t.456 gcc labels in google. I dont think I found
> anything interesting. Are we looking at not listing symbols that end
> with @plt? Can you please list an example t.456 label. Also any pointers to
> where I can find more information on the same would be very useful.

I guess this is what he means:

[acme(a)doppio linux-2.6-tip]$ grep ' [TtWw] .\+\.' /proc/kallsyms | head -5
ffffffff81000646 t trace_kmalloc.clone.0
ffffffff810006ac t create_dev.clone.0
ffffffff81006ae4 t test_ti_thread_flag.clone.0
ffffffff8100a388 t trace_power_start.clone.0
ffffffff8100ad8d t user_regset_copyin.clone.0
[acme(a)doppio linux-2.6-tip]$ readelf -s ../build/v2.6.35-rc5-tip+/vmlinux | grep ' FUNC .\+\.' | head -5
165: ffffffff81000646 101 FUNC LOCAL DEFAULT 1 trace_kmalloc.clone.0
180: ffffffff810006ac 44 FUNC LOCAL DEFAULT 1 create_dev.clone.0
438: ffffffff81006ae4 22 FUNC LOCAL DEFAULT 1 test_ti_thread_flag.clone
510: ffffffff81ae5c40 136 FUNC LOCAL DEFAULT 22 e820_end_pfn.clone.0
750: ffffffff8100a388 65 FUNC LOCAL DEFAULT 1 trace_power_start.clone.0
[acme(a)doppio linux-2.6-tip]$

Or at least those are the ones with dots here.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Removing dead ARCH_GUMSTIX_ORIG
Next: What's the relationship between Linux driver running priority and FIFO policy?