Skip to contentSkip to conversation

uprobe symbols with @GLIBC...

DISCUSSION Paul Clarke 3 participants 6 messages Feb 20, 2015 – Mar 30, 2017 perf events

lore
Share & tools
lore
#0 lore raw

Greetings,

(New user for perf probe -x...)

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
# perf probe -v -x /lib/libpthread.so.0 pthread_create@GLIBC_2.0
probe-definition(0): pthread_create@GLIBC_2.0
symbol:pthread_create file:GLIBC_2.0 line:0 offset:0 return:0 lazy:(null)
0 arguments
Failed to open debuginfo file.
  Error: Failed to add events. (-2)
# perf probe -v -x /lib/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
Could not open debuginfo. Try to use symbols.
no symbols found in /usr/lib/libpthread-2.18.so, maybe install a debug package?
Failed to find symbol pthread_create in /usr/lib/libpthread-2.18.so
  Error: Failed to add events. (-2)

Symbols without such qualifiers work fine:

# perf probe -F -x /lib/libpthread.so.0 --filter='pthread_detach*'
pthread_detach
# perf probe -v -x /lib/libpthread.so.0 pthread_detach
probe-definition(0): pthread_detach
symbol:pthread_detach file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Could not open debuginfo. Try to use symbols.
Opening /sys/kernel/debug/tracing/uprobe_events write=1
Added new event:
Writing event: p:probe_libpthread/pthread_detach /usr/lib/libpthread-2.18.so:0x8b30
  probe_libpthread:pthread_detach (on pthread_detach in 
/usr/lib/libpthread-2.18.so)

You can now use it in all perf tools, such as:

perf record -e probe_libpthread:pthread_detach -aR sleep 1

--
Regards,
Paul Clarke, IBM

#1 lore raw
Quoted 10 lines · Paul Clarke

Greetings,

(New user for perf probe -x...)

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.

David

Quoted 48 lines
# perf probe -v -x /lib/libpthread.so.0 pthread_create@GLIBC_2.0
probe-definition(0): pthread_create@GLIBC_2.0
symbol:pthread_create file:GLIBC_2.0 line:0 offset:0 return:0 lazy:(null)
0 arguments
Failed to open debuginfo file.
   Error: Failed to add events. (-2)
# perf probe -v -x /lib/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
Could not open debuginfo. Try to use symbols.
no symbols found in /usr/lib/libpthread-2.18.so, maybe install a debug
package?
Failed to find symbol pthread_create in /usr/lib/libpthread-2.18.so
   Error: Failed to add events. (-2)

Symbols without such qualifiers work fine:

# perf probe -F -x /lib/libpthread.so.0 --filter='pthread_detach*'
pthread_detach
# perf probe -v -x /lib/libpthread.so.0 pthread_detach
probe-definition(0): pthread_detach
symbol:pthread_detach file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Could not open debuginfo. Try to use symbols.
Opening /sys/kernel/debug/tracing/uprobe_events write=1
Added new event:
Writing event: p:probe_libpthread/pthread_detach
/usr/lib/libpthread-2.18.so:0x8b30
   probe_libpthread:pthread_detach (on pthread_detach in
/usr/lib/libpthread-2.18.so)

You can now use it in all perf tools, such as:

perf record -e probe_libpthread:pthread_detach -aR sleep 1

--
Regards,
Paul Clarke, IBM

--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
Quoted 8 lines · David Ahern
Quoted 6 lines · Paul Clarke

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
Quoted 6 lines

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

Quoted 22 lines
Quoted 22 lines
# perf probe -v -x /lib/libpthread.so.0 pthread_create@GLIBC_2.0
probe-definition(0): pthread_create@GLIBC_2.0
symbol:pthread_create file:GLIBC_2.0 line:0 offset:0 return:0 lazy:(null)
0 arguments
Failed to open debuginfo file.
   Error: Failed to add events. (-2)
# perf probe -v -x /lib/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
Could not open debuginfo. Try to use symbols.
no symbols found in /usr/lib/libpthread-2.18.so, maybe install a debug
package?
Failed to find symbol pthread_create in /usr/lib/libpthread-2.18.so
   Error: Failed to add events. (-2)

Symbols without such qualifiers work fine:

# perf probe -F -x /lib/libpthread.so.0 --filter='pthread_detach*'
pthread_detach
Quoted 11 lines
Quoted 11 lines
# perf probe -v -x /lib/libpthread.so.0 pthread_detach
probe-definition(0): pthread_detach
symbol:pthread_detach file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Could not open debuginfo. Try to use symbols.
Opening /sys/kernel/debug/tracing/uprobe_events write=1
Added new event:
Writing event: p:probe_libpthread/pthread_detach
/usr/lib/libpthread-2.18.so:0x8b30
   probe_libpthread:pthread_detach (on pthread_detach in
/usr/lib/libpthread-2.18.so)

--
PC

#3 lore raw

On 02/20/2015 11:57 AM, Paul Clarke wrote:

(Yes, 2 years later. :-)

Quoted 28 lines · David Ahern
Quoted 8 lines · Paul Clarke
Quoted 6 lines

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
Quoted 6 lines

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 --

Quoted 8 lines

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
--
tools/perf/util/map.c +17 -1
index 4f9a71c..998b640 100644
@@ -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)

--
Regards,
Paul Clarke, IBM

#4 lore raw

[ cc Masami ]

Quoted 141 lines · Paul Clarke

On 02/20/2015 11:57 AM, Paul Clarke wrote:

(Yes, 2 years later. :-)

Quoted 29 lines · David Ahern
Quoted 8 lines · Paul Clarke
Quoted 6 lines

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
Quoted 7 lines

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 --

Quoted 8 lines

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:

Signature · 53 lines
$ 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 <[email protected]>
tools/perf/util/map.c +17 -1
index 4f9a71c..998b640 100644
@@ -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;
 }
 
Quoted 1 line

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.

#5 lore raw
Quoted 145 lines · On Wed, 29 Mar 2017 10:23:49 -0600 David Ahern <[email protected]> wrote:

[ cc Masami ]

Quoted 141 lines · Paul Clarke

On 02/20/2015 11:57 AM, Paul Clarke wrote:

(Yes, 2 years later. :-)

Quoted 29 lines · David Ahern
Quoted 8 lines · Paul Clarke
Quoted 6 lines

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
Quoted 7 lines

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 --

Quoted 8 lines

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:

Signature · 53 lines
$ 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 <[email protected]>
tools/perf/util/map.c +17 -1
index 4f9a71c..998b640 100644
@@ -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;
 }
 
Quoted 5 lines
Quoted 1 line

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.

Right, I see this is an arch independant issue (since I can see same issue on x86). IMO, we need a wrapper function (e.g. compare_symbol_names) and use it in caller sites.

Thank you,

Quoted 1 line
Signature · 1 line
Masami Hiramatsu <[email protected]>