Re: uprobe symbols with @GLIBC...

[David Ahern <dsahern@gmail.com>]

[ cc Masami ]

On 3/27/17 3:49 PM, Paul Clarke wrote:
> On 02/20/2015 11:57 AM, Paul Clarke wrote:
> 
> (Yes, 2 years later.  :-)
> 
>> On 02/20/2015 11:20 AM, David Ahern wrote:
>>> On 2/20/15 8:29 AM, Paul Clarke wrote:
>>>> How does one set a dynamic tracepoint for user-mode symbols with "@"
>>>> qualifiers?
>>>>
>>>> # perf probe -F -x /lib/libpthread.so.0 --filter='pthread_create*'
>>>> pthread_create@@GLIBC_2.1
>>>> pthread_create@GLIBC_2.0
>>>
>>> one of many reasons I proposed an option to let users specify an
>>> address.
>>>
>>> https://lkml.org/lkml/2013/12/1/126
>>> https://lkml.org/lkml/2013/12/2/324
>>>
>>> It was not picked up.
>>
>> I presume then, that I'm not doing something obviously wrong, and this
>> is the current state of affairs?
>>
>> Given that, I would argue that a better resolution would be to:
>>
>> 1. Support setting probes using the name of the symbol as reported by
>> "--funcs".  For example, the following should work:
>>
>> # perf probe -x /lib/libpthread.so.0 pthread_create@GLIBC_2.0
>>
>> -- AND / OR --
>>
>> 2. Go ahead and just set probes at all functions which match the base
>> function name.  For example, the following:
>>
>> # perf probe -v -x /lib/libpthread.so.0 pthread_create
>>
>> Would set probes at both known "pthread_create" entry points:
>> - pthread_create@@GLIBC_2.1
>> - pthread_create@GLIBC_2.0
> 
> I created a patch implementing something close to the latter, but only
> picking up the default symbol (double-"@").  I submit to spark discussion,
> not that I necessarily consider this patch complete or correct.
> 
> -- >8 --
> 
> Allow user probes on versioned symbols.
> 
> Symbol versioning, as in glibc, results in symbols being defined as:
> <real symbol>@[@]<version>
> (Note that "@@" identifies a default symbol, if the symbol name
> is repeated.)
> 
> perf is currently unable to deal with this, and is unable to create
> user probes at such symbols:
> -- 
> $ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
> 0000000000008d30 t __pthread_create_2_1
> 0000000000008d30 T pthread_create@@GLIBC_2.17
> $ /usr/bin/sudo perf probe -v -x
> /lib/powerpc64le-linux-gnu/libpthread.so.0 pthread_create
> probe-definition(0): pthread_create
> symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
> 0 arguments
> Open Debuginfo file:
> /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
> Try to find probe point from debuginfo.
> Probe point 'pthread_create' not found.
>   Error: Failed to add events. Reason: No such file or directory (Code: -2)
> -- 
> 
> One is not able to specify the fully versioned symbol, either, due to
> syntactic conflicts with other uses of "@" by perf:
> -- 
> $ /usr/bin/sudo perf probe -v -x
> /lib/powerpc64le-linux-gnu/libpthread.so.0 pthread_create@@GLIBC_2.17
> probe-definition(0): pthread_create@@GLIBC_2.17
> Semantic error :SRC@SRC is not allowed.
> 0 arguments
>   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
> -- 
> 
> The attached patch ignores versioning for default symbols, thus
> allowing probes to be created for these symbols:
> -- 
> $ /usr/bin/sudo ./perf probe -x
> /lib/powerpc64le-linux-gnu/libpthread.so.0 pthread_create
> Added new event:
>   probe_libpthread:pthread_create (on pthread_create in
> /lib/powerpc64le-linux-gnu/libpthread-2.19.so)
> 
> You can now use it in all perf tools, such as:
> 
>         perf record -e probe_libpthread:pthread_create -aR sleep 1
> 
> $ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR
> ./test 2
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
> $ /usr/bin/sudo ./perf script
>             test  2915 [000] 19124.260729:
> probe_libpthread:pthread_create: (3fff99248d38)
>             test  2916 [000] 19124.260962:
> probe_libpthread:pthread_create: (3fff99248d38)
> $ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
> Removed event: probe_libpthread:pthread_create
> -- 
> 
> Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
> 
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index 4f9a71c..998b640 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -327,7 +327,23 @@ int map__load(struct map *map)
>  
>  int __weak arch__compare_symbol_names(const char *namea, const char
> *nameb)
>  {
> -    return strcmp(namea, nameb);
> +    int rc;
> +    const char *namea_versioning, *nameb_versioning;
> +
> +    namea_versioning = strstr(namea,"@@");
> +    if (namea_versioning)
> +        namea = strndup(namea,namea_versioning-namea);
> +
> +    nameb_versioning = strstr(nameb,"@@");
> +    if (nameb_versioning)
> +        nameb = strndup(nameb,nameb_versioning-nameb);
> +
> +    rc = strcmp(namea, nameb);
> +
> +    if (namea_versioning) free((void *)namea);
> +    if (nameb_versioning) free((void *)nameb);
> +
> +    return rc;
>  }
>  
>  struct symbol *map__find_symbol(struct map *map, u64 addr)


Generic code should not be put that in an arch__ function; perhaps a
compare_symbol_names that does the checks and the arch one.