Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1277260 > unrolled thread

[PATCH] perf probe: Adjust dso->long_name for offline module

Started byWang Nan <wangnan0@huawei.com>
First post2015-11-25 12:40 +0100
Last post2015-11-27 08:50 +0100
Articles 9 — 5 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] perf probe: Adjust dso->long_name for offline module Wang Nan <wangnan0@huawei.com> - 2015-11-25 12:40 +0100
    Re: [PATCH] perf probe: Adjust dso->long_name for offline module Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-11-25 20:40 +0100
      Re: [PATCH] perf probe: Adjust dso->long_name for offline module "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-26 04:30 +0100
    RE: [PATCH] perf probe: Adjust dso->long_name for offline module 平松雅巳 / HIRAMATU，MASAMI   <masami.hiramatsu.pt@hitachi.com> - 2015-11-26 02:20 +0100
      Re: [PATCH] perf probe: Adjust dso->long_name for offline module "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-26 02:40 +0100
    [PATCH v2] perf probe: Adjust dso->long_name for offline module Wang Nan <wangnan0@huawei.com> - 2015-11-26 04:30 +0100
    [PATCH v3] perf probe: Adjust dso->long_name for offline module Wang Nan <wangnan0@huawei.com> - 2015-11-26 05:10 +0100
      Re: [PATCH v3] perf probe: Adjust dso->long_name for offline module Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-11-26 17:50 +0100
      [tip:perf/core] perf machine: Adjust dso->  long_name for offline module tip-bot for Wang Nan <tipbot@zytor.com> - 2015-11-27 08:50 +0100

#1277260 — [PATCH] perf probe: Adjust dso->long_name for offline module

FromWang Nan <wangnan0@huawei.com>
Date2015-11-25 12:40 +0100
Subject[PATCH] perf probe: Adjust dso->long_name for offline module
Message-ID<qyGAy-5Fi-7@gated-at.bofh.it>
If libelf unable to open debuginfo for an offline module but the ko has
symtab, something unexpected may happen.

 # rm -rf ~/.debug/
 # mv /usr/lib64/elfutils/libebl_x86_64.so{,.bak}
 # ./perf probe -m /home/wangnan/kmodule/mymodule.ko my_func
 [mymodule] with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
 Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
   Error: Failed to add events
 # ./perf buildid-cache -a ./mymodule.ko
 # ./perf probe -m /home/wangnan/kmodule/mymodule.ko my_func
 Added new event:
   probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)

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

	 perf record -e probe:my_func -aR sleep 1

In the above example, probe fails if it isn't in buildid-cache. However,
user would expect it success in both case because perf is able to find
probe points actually.

The problem is because perf won't utilize module's full path if it
failed to open debuginfo. In
 convert_to_probe_trace_events ->
 find_probe_trace_events_from_map ->
 get_target_map ->
 kernel_get_module_map ->
 machine__findnew_module_map ->
 map_groups__find_by_name

map_groups__find_by_name() is able to find the map of that module, but
this information is found from /proc/modules before it knows the real
path of the offline module. Therefore, the map->dso->long_name is
set to something like '[mymodule]', which prevents dso__load() find
the real path of the module file.

In another aspect, if dso__load() can get the offline module through
buildid cache, it can read symble table from that ko. Even if debuginfo
is not available, 'perf probe' can success if the '.symtab' can be
found.

This patch fixes long_name so dso__load() is able to find module's path
and read symbol table in this case.

After this patch:

 # rm -rf ~/.debug/
 # mv /usr/lib64/elfutils/libebl_x86_64.so{,.bak}
 # ./perf probe -m /home/wangnan/kmodule/mymodule.ko my_func
 Added new event:
   probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)

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

 	perf record -e probe:my_func -aR sleep 1

 # mv /usr/lib64/elfutils/libebl_x86_64.so{.bak,}

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
---
 tools/perf/util/probe-event.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 93996ec..ea4f79f 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2516,6 +2516,7 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev,
 	struct probe_trace_point *tp;
 	int num_matched_functions;
 	int ret, i, j, skipped = 0;
+	const char *dup_filename;
 
 	map = get_target_map(pev->target, pev->uprobes);
 	if (!map) {
@@ -2523,6 +2524,21 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev,
 		goto out;
 	}
 
+	/*
+	 * If the map's dso is an offline module, give dso__load() a chance
+	 * to find the file path of that module by fixing long_name.
+	 */
+	if (map->dso && strchr(pev->target, '/')) {
+		if (!map->dso->long_name || map->dso->long_name[0] == '[') {
+			dup_filename = strdup(pev->target);
+			if (!dup_filename) {
+				ret = -ENOMEM;
+				goto out;
+			}
+			dso__set_long_name(map->dso, dup_filename, true);
+		}
+	}
+
 	syms = malloc(sizeof(struct symbol *) * probe_conf.max_probes);
 	if (!syms) {
 		ret = -ENOMEM;
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1277742

FromArnaldo Carvalho de Melo <acme@kernel.org>
Date2015-11-25 20:40 +0100
Message-ID<qyO56-266-47@gated-at.bofh.it>
In reply to#1277260
Em Wed, Nov 25, 2015 at 11:30:59AM +0000, Wang Nan escreveu:
> If libelf unable to open debuginfo for an offline module but the ko has
> symtab, something unexpected may happen.
> 
>  # rm -rf ~/.debug/
>  # mv /usr/lib64/elfutils/libebl_x86_64.so{,.bak}
>  # ./perf probe -m /home/wangnan/kmodule/mymodule.ko my_func
>  [mymodule] with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
>  Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko

Understood, since we are giving the path to that module, we can, if its
build-id matches the one for the online module, use it, is that the
case, i.e. do we check, int his scenario, that the build-id matches?

- Arnaldo

>    Error: Failed to add events
>  # ./perf buildid-cache -a ./mymodule.ko
>  # ./perf probe -m /home/wangnan/kmodule/mymodule.ko my_func
>  Added new event:
>    probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)
> 
>  You can now use it in all perf tools, such as:
> 
> 	 perf record -e probe:my_func -aR sleep 1
> 
> In the above example, probe fails if it isn't in buildid-cache. However,
> user would expect it success in both case because perf is able to find
> probe points actually.
> 
> The problem is because perf won't utilize module's full path if it
> failed to open debuginfo. In
>  convert_to_probe_trace_events ->
>  find_probe_trace_events_from_map ->
>  get_target_map ->
>  kernel_get_module_map ->
>  machine__findnew_module_map ->
>  map_groups__find_by_name
> 
> map_groups__find_by_name() is able to find the map of that module, but
> this information is found from /proc/modules before it knows the real
> path of the offline module. Therefore, the map->dso->long_name is
> set to something like '[mymodule]', which prevents dso__load() find
> the real path of the module file.
> 
> In another aspect, if dso__load() can get the offline module through
> buildid cache, it can read symble table from that ko. Even if debuginfo
> is not available, 'perf probe' can success if the '.symtab' can be
> found.
> 
> This patch fixes long_name so dso__load() is able to find module's path
> and read symbol table in this case.
> 
> After this patch:
> 
>  # rm -rf ~/.debug/
>  # mv /usr/lib64/elfutils/libebl_x86_64.so{,.bak}
>  # ./perf probe -m /home/wangnan/kmodule/mymodule.ko my_func
>  Added new event:
>    probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)
> 
>  You can now use it in all perf tools, such as:
> 
>  	perf record -e probe:my_func -aR sleep 1
> 
>  # mv /usr/lib64/elfutils/libebl_x86_64.so{.bak,}
> 
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Zefan Li <lizefan@huawei.com>
> Cc: pi3orama@163.com
> ---
>  tools/perf/util/probe-event.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 93996ec..ea4f79f 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -2516,6 +2516,7 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev,
>  	struct probe_trace_point *tp;
>  	int num_matched_functions;
>  	int ret, i, j, skipped = 0;
> +	const char *dup_filename;
>  
>  	map = get_target_map(pev->target, pev->uprobes);
>  	if (!map) {
> @@ -2523,6 +2524,21 @@ static int find_probe_trace_events_from_map(struct perf_probe_event *pev,
>  		goto out;
>  	}
>  
> +	/*
> +	 * If the map's dso is an offline module, give dso__load() a chance
> +	 * to find the file path of that module by fixing long_name.
> +	 */
> +	if (map->dso && strchr(pev->target, '/')) {
> +		if (!map->dso->long_name || map->dso->long_name[0] == '[') {
> +			dup_filename = strdup(pev->target);
> +			if (!dup_filename) {
> +				ret = -ENOMEM;
> +				goto out;
> +			}
> +			dso__set_long_name(map->dso, dup_filename, true);
> +		}
> +	}
> +
>  	syms = malloc(sizeof(struct symbol *) * probe_conf.max_probes);
>  	if (!syms) {
>  		ret = -ENOMEM;
> -- 
> 1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277959

From"Wangnan (F)" <wangnan0@huawei.com>
Date2015-11-26 04:30 +0100
Message-ID<qyVpU-7d5-3@gated-at.bofh.it>
In reply to#1277742

On 2015/11/26 3:35, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 25, 2015 at 11:30:59AM +0000, Wang Nan escreveu:
>> If libelf unable to open debuginfo for an offline module but the ko has
>> symtab, something unexpected may happen.
>>
>>   # rm -rf ~/.debug/
>>   # mv /usr/lib64/elfutils/libebl_x86_64.so{,.bak}
>>   # ./perf probe -m /home/wangnan/kmodule/mymodule.ko my_func
>>   [mymodule] with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
>>   Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
> Understood, since we are giving the path to that module, we can, if its
> build-id matches the one for the online module, use it, is that the
> case, i.e. do we check, int his scenario, that the build-id matches?

Please see my test result in v2 patch [1]. In symsrc__init() build-id
would be checked.

[1] 
http://lkml.kernel.org/r/1448507949-187812-1-git-send-email-wangnan0@huawei.com

  # ./perf probe -m ./mymodule.ko my_func
  Added new event:
    probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)

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

  	perf record -e probe:my_func -aR sleep 1

  # ./perf probe -d '*'
  Removed event: probe:my_func
  # mv ./mymodule.{ko,.bak}
  # mv ./moduleb.ko mymodule.ko
  # ./perf probe -m ./mymodule.ko my_func
  /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
  Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
    Error: Failed to add events.

  # ./perf probe -v -m ./mymodule.ko my_func
  probe-definition(0): my_func
  symbol:my_funcfile:(null)  line:0 offset:0 return:0 lazy:(null)
  0 arguments
  Could not open debuginfo. Try to use symbols.
  symsrc__init: build id mismatch for /home/wangnan/kmodule/mymodule.ko.
  /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
  Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
    Error: Failed to add events. Reason: No such file or directory (Code: -2)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277925

From平松雅巳 / HIRAMATU，MASAMI <masami.hiramatsu.pt@hitachi.com>
Date2015-11-26 02:20 +0100
Message-ID<qyTo5-5Cu-9@gated-at.bofh.it>
In reply to#1277260
RnJvbTogV2FuZyBOYW4gW21haWx0bzp3YW5nbmFuMEBodWF3ZWkuY29tXQ0KPg0KPklmIGxpYmVs
ZiB1bmFibGUgdG8gb3BlbiBkZWJ1Z2luZm8gZm9yIGFuIG9mZmxpbmUgbW9kdWxlIGJ1dCB0aGUg
a28gaGFzDQo+c3ltdGFiLCBzb21ldGhpbmcgdW5leHBlY3RlZCBtYXkgaGFwcGVuLg0KPg0KPiAj
IHJtIC1yZiB+Ly5kZWJ1Zy8NCj4gIyBtdiAvdXNyL2xpYjY0L2VsZnV0aWxzL2xpYmVibF94ODZf
NjQuc297LC5iYWt9DQoNClBsZWFzZSBkbyBnaXZlIG1vcmUgcG9zc2libGUgdXNlY2FzZS4gcmVt
b3ZpbmcgbGliZWJsIGlzIGNyYXp5LA0KYW5kIGJyb2tlbiBlbnZpcm9ubWVudC4NCg0KSWYgeW91
J2QgbGlrZSB0byB1c2UgcGVyZiBwcm9iZSB3aXRob3V0IGRlYnVnaW5mbywgbWFrZSBOT19EV0FS
Rj0xIG9yDQpzdHJpcCB0aGUgdGFyZ2V0IGJpbmFyeS4NCg0KPiAjIC4vcGVyZiBwcm9iZSAtbSAv
aG9tZS93YW5nbmFuL2ttb2R1bGUvbXltb2R1bGUua28gbXlfZnVuYw0KPiBbbXltb2R1bGVdIHdp
dGggYnVpbGQgaWQgMzI2YWI0MjU1MGVmM2QyNDk0NGY1M2M4MTc1MzM3MjgzNjdlZmZlYiBub3Qg
Zm91bmQsIGNvbnRpbnVpbmcgd2l0aG91dCBzeW1ib2xzDQo+IEZhaWxlZCB0byBmaW5kIHN5bWJv
bCBteV9mdW5jIGluIC9ob21lL3dhbmduYW4va21vZHVsZS9teW1vZHVsZS5rbw0KPiAgIEVycm9y
OiBGYWlsZWQgdG8gYWRkIGV2ZW50cw0KPiAjIC4vcGVyZiBidWlsZGlkLWNhY2hlIC1hIC4vbXlt
b2R1bGUua28NCj4gIyAuL3BlcmYgcHJvYmUgLW0gL2hvbWUvd2FuZ25hbi9rbW9kdWxlL215bW9k
dWxlLmtvIG15X2Z1bmMNCj4gQWRkZWQgbmV3IGV2ZW50Og0KPiAgIHByb2JlOm15X2Z1bmMgICAg
ICAgIChvbiBteV9mdW5jIGluIC9ob21lL3dhbmduYW4va21vZHVsZS9teW1vZHVsZS5rbykNCj4N
Cj4gWW91IGNhbiBub3cgdXNlIGl0IGluIGFsbCBwZXJmIHRvb2xzLCBzdWNoIGFzOg0KPg0KPgkg
cGVyZiByZWNvcmQgLWUgcHJvYmU6bXlfZnVuYyAtYVIgc2xlZXAgMQ0KPg0KPkluIHRoZSBhYm92
ZSBleGFtcGxlLCBwcm9iZSBmYWlscyBpZiBpdCBpc24ndCBpbiBidWlsZGlkLWNhY2hlLiBIb3dl
dmVyLA0KPnVzZXIgd291bGQgZXhwZWN0IGl0IHN1Y2Nlc3MgaW4gYm90aCBjYXNlIGJlY2F1c2Ug
cGVyZiBpcyBhYmxlIHRvIGZpbmQNCj5wcm9iZSBwb2ludHMgYWN0dWFsbHkuDQo+DQo+VGhlIHBy
b2JsZW0gaXMgYmVjYXVzZSBwZXJmIHdvbid0IHV0aWxpemUgbW9kdWxlJ3MgZnVsbCBwYXRoIGlm
IGl0DQo+ZmFpbGVkIHRvIG9wZW4gZGVidWdpbmZvLiBJbg0KPiBjb252ZXJ0X3RvX3Byb2JlX3Ry
YWNlX2V2ZW50cyAtPg0KPiBmaW5kX3Byb2JlX3RyYWNlX2V2ZW50c19mcm9tX21hcCAtPg0KPiBn
ZXRfdGFyZ2V0X21hcCAtPg0KPiBrZXJuZWxfZ2V0X21vZHVsZV9tYXAgLT4NCj4gbWFjaGluZV9f
ZmluZG5ld19tb2R1bGVfbWFwIC0+DQo+IG1hcF9ncm91cHNfX2ZpbmRfYnlfbmFtZQ0KPg0KPm1h
cF9ncm91cHNfX2ZpbmRfYnlfbmFtZSgpIGlzIGFibGUgdG8gZmluZCB0aGUgbWFwIG9mIHRoYXQg
bW9kdWxlLCBidXQNCj50aGlzIGluZm9ybWF0aW9uIGlzIGZvdW5kIGZyb20gL3Byb2MvbW9kdWxl
cyBiZWZvcmUgaXQga25vd3MgdGhlIHJlYWwNCj5wYXRoIG9mIHRoZSBvZmZsaW5lIG1vZHVsZS4g
VGhlcmVmb3JlLCB0aGUgbWFwLT5kc28tPmxvbmdfbmFtZSBpcw0KPnNldCB0byBzb21ldGhpbmcg
bGlrZSAnW215bW9kdWxlXScsIHdoaWNoIHByZXZlbnRzIGRzb19fbG9hZCgpIGZpbmQNCj50aGUg
cmVhbCBwYXRoIG9mIHRoZSBtb2R1bGUgZmlsZS4NCg0KSG1tLCBpZiBzbywgaXQgc2hvdWxkIGJl
IGZpeGVkIGluIG1hcCBvciBtYWNoaW5lLCBub3QgaW4gcHJvYmUtZXZlbnQuYy4NCg0KVGhhbmtz
LA0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277929

From"Wangnan (F)" <wangnan0@huawei.com>
Date2015-11-26 02:40 +0100
Message-ID<qyTHs-5JO-11@gated-at.bofh.it>
In reply to#1277925

On 2015/11/26 9:10, 平松雅巳 / HIRAMATU，MASAMI wrote:
> From: Wang Nan [mailto:wangnan0@huawei.com]
>> If libelf unable to open debuginfo for an offline module but the ko has
>> symtab, something unexpected may happen.
>>
>> # rm -rf ~/.debug/
>> # mv /usr/lib64/elfutils/libebl_x86_64.so{,.bak}
> Please do give more possible usecase. removing libebl is crazy,
> and broken environment.

It is a real problem we met, where perf itself is statically linked
and copied to target platform.

> If you'd like to use perf probe without debuginfo, make NO_DWARF=1 or
> strip the target binary.

Can't simply stripping the target binary because the symtab would
also be stipped out.

>> # ./perf probe -m /home/wangnan/kmodule/mymodule.ko my_func
>> [mymodule] with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
>> Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
>>    Error: Failed to add events
>> # ./perf buildid-cache -a ./mymodule.ko
>> # ./perf probe -m /home/wangnan/kmodule/mymodule.ko my_func
>> Added new event:
>>    probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)
>>
>> You can now use it in all perf tools, such as:
>>
>> 	 perf record -e probe:my_func -aR sleep 1
>>
>> In the above example, probe fails if it isn't in buildid-cache. However,
>> user would expect it success in both case because perf is able to find
>> probe points actually.
>>
>> The problem is because perf won't utilize module's full path if it
>> failed to open debuginfo. In
>> convert_to_probe_trace_events ->
>> find_probe_trace_events_from_map ->
>> get_target_map ->
>> kernel_get_module_map ->
>> machine__findnew_module_map ->
>> map_groups__find_by_name
>>
>> map_groups__find_by_name() is able to find the map of that module, but
>> this information is found from /proc/modules before it knows the real
>> path of the offline module. Therefore, the map->dso->long_name is
>> set to something like '[mymodule]', which prevents dso__load() find
>> the real path of the module file.
> Hmm, if so, it should be fixed in map or machine, not in probe-event.c.

Will do in next version.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277958 — [PATCH v2] perf probe: Adjust dso->long_name for offline module

FromWang Nan <wangnan0@huawei.com>
Date2015-11-26 04:30 +0100
Subject[PATCH v2] perf probe: Adjust dso->long_name for offline module
Message-ID<qyVpT-7d5-1@gated-at.bofh.it>
In reply to#1277260
Something unexpected may happen if copy statically linked perf to a
production environment:

 # ./perf probe -m ./mymodule.ko my_func
 [mymodule] with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
 Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
   Error: Failed to add events.
 # ./perf buildid-cache -a ./mymodule.ko
 # ./perf probe -m ./mymodule.ko my_func
 Added new event:
   probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)

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

 	perf record -e probe:my_func -aR sleep 1

Where:

 # ldd ./perf
	not a dynamic executable
 # strace -e open ./perf probe -m ./mymodule.ko my_func
 ...
 open("/home/wangnan/kmodule/mymodule.ko", O_RDONLY) = 3
 open("/home/wangnan/kmodule/../lib64/elfutils/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 ...
 open("/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 open("/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 open("/usr/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 open("/usr/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 open("[mymodule]", O_RDONLY)            = -1 ENOENT (No such file or directory)
 open("/home/wangnan/.debug/.build-id/32/6ab42550ef3d24944f53c817533728367effeb", O_RDONLY) = -1 ENOENT (No such file or directory)
 open("[mymodule]", O_RDONLY)            = -1 ENOENT (No such file or directory)

In the above example, probe fails before we put the module into
buildid-cache. However, user would expect it success in both case
because perf is able to find probe points actually.

The reason is because perf won't utilize module's full path if it
failed to open debuginfo. In
 convert_to_probe_trace_events ->
 find_probe_trace_events_from_map ->
 get_target_map ->
 kernel_get_module_map ->
 machine__findnew_module_map ->
 map_groups__find_by_name

map_groups__find_by_name() is able to find the map of that module, but
this information is found from /proc/module before it knows the real
path of the offline module. Therefore, the map->dso->long_name is
set to something like '[mymodule]', which prevent dso__load() find
the real path of the module file.

In another aspect, if dso__load() can get the offline module through
buildid cache, it can read symble table from that ko. Even if debuginfo
is not available, 'perf probe' can success if the '.symtab' can be
found.

This patch improves machine__findnew_module_map(): when dso->long_name
is leading with '[' (doesn't find path of module when parsing
/proc/modules), fixes it by dso__set_long_name(), so following
dso__load() is possible to find the symbol table.

This patch won't interfere with buildid matching. Here is the test
result:

 # ./perf probe -m ./mymodule.ko my_func
 Added new event:
   probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)

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

 	perf record -e probe:my_func -aR sleep 1

 # ./perf probe -d '*'
 Removed event: probe:my_func
 # mv ./mymodule.{ko,.bak}
 # mv ./moduleb.ko mymodule.ko
 # ./perf probe -m ./mymodule.ko my_func
 /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
 Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
   Error: Failed to add events.

 # ./perf probe -v -m ./mymodule.ko my_func
 probe-definition(0): my_func
 symbol:my_func file:(null) line:0 offset:0 return:0 lazy:(null)
 0 arguments
 Could not open debuginfo. Try to use symbols.
 symsrc__init: build id mismatch for /home/wangnan/kmodule/mymodule.ko.
 /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
 Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
   Error: Failed to add events. Reason: No such file or directory (Code: -2)

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
---
 tools/perf/util/machine.c | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 7f5071a..cdfa97f 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -561,6 +561,24 @@ int machine__process_switch_event(struct machine *machine __maybe_unused,
 	return 0;
 }
 
+static void adjust_dso_long_name(struct map *map, const char *filename)
+{
+	const char *dup_filename;
+
+	if (!filename || !map->dso || !map->dso->long_name)
+		return;
+	if (map->dso->long_name[0] != '[')
+		return;
+	if (!strchr(filename, '/'))
+		return;
+
+	dup_filename = strdup(filename);
+	if (!dup_filename)
+		return;
+
+	dso__set_long_name(map->dso, filename, true);
+}
+
 struct map *machine__findnew_module_map(struct machine *machine, u64 start,
 					const char *filename)
 {
@@ -573,8 +591,15 @@ struct map *machine__findnew_module_map(struct machine *machine, u64 start,
 
 	map = map_groups__find_by_name(&machine->kmaps, MAP__FUNCTION,
 				       m.name);
-	if (map)
+	if (map) {
+		/*
+		 * If the map's dso is an offline module, give dso__load()
+		 * a chance to find the file path of that module by fixing
+		 * long_name.
+		 */
+		adjust_dso_long_name(map, filename);
 		goto out;
+	}
 
 	dso = machine__findnew_module_dso(machine, &m, filename);
 	if (dso == NULL)
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277966 — [PATCH v3] perf probe: Adjust dso->long_name for offline module

FromWang Nan <wangnan0@huawei.com>
Date2015-11-26 05:10 +0100
Subject[PATCH v3] perf probe: Adjust dso->long_name for offline module
Message-ID<qyW2C-7N7-3@gated-at.bofh.it>
In reply to#1277260
Something unexpected may happen if copy statically linked perf to a
production environment:

 # ./perf probe -m ./mymodule.ko my_func
 [mymodule] with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
 Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
   Error: Failed to add events.
 # ./perf buildid-cache -a ./mymodule.ko
 # ./perf probe -m ./mymodule.ko my_func
 Added new event:
   probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)

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

 	perf record -e probe:my_func -aR sleep 1

Where:

 # ldd ./perf
	not a dynamic executable
 # strace -e open ./perf probe -m ./mymodule.ko my_func
 ...
 open("/home/wangnan/kmodule/mymodule.ko", O_RDONLY) = 3
 open("/home/wangnan/kmodule/../lib64/elfutils/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 ...
 open("/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 open("/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 open("/usr/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 open("/usr/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 open("[mymodule]", O_RDONLY)            = -1 ENOENT (No such file or directory)
 open("/home/wangnan/.debug/.build-id/32/6ab42550ef3d24944f53c817533728367effeb", O_RDONLY) = -1 ENOENT (No such file or directory)
 open("[mymodule]", O_RDONLY)            = -1 ENOENT (No such file or directory)

In the above example, probe fails before we put the module into
buildid-cache. However, user would expect it success in both case
because perf is able to find probe points actually.

The reason is because perf won't utilize module's full path if it
failed to open debuginfo. In
 convert_to_probe_trace_events ->
 find_probe_trace_events_from_map ->
 get_target_map ->
 kernel_get_module_map ->
 machine__findnew_module_map ->
 map_groups__find_by_name

map_groups__find_by_name() is able to find the map of that module, but
this information is found from /proc/module before it knows the real
path of the offline module. Therefore, the map->dso->long_name is
set to something like '[mymodule]', which prevent dso__load() find
the real path of the module file.

In another aspect, if dso__load() can get the offline module through
buildid cache, it can read symble table from that ko. Even if debuginfo
is not available, 'perf probe' can success if the '.symtab' can be
found.

This patch improves machine__findnew_module_map(): when dso->long_name
is leading with '[' (doesn't find path of module when parsing
/proc/modules), fixes it by dso__set_long_name(), so following
dso__load() is possible to find the symbol table.

This patch won't interfere with buildid matching. Here is the test
result:

 # ./perf probe -m ./mymodule.ko my_func
 Added new event:
   probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)

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

 	perf record -e probe:my_func -aR sleep 1

 # ./perf probe -d '*'
 Removed event: probe:my_func
 # mv ./mymodule.{ko,.bak}
 # mv ./moduleb.ko mymodule.ko
 # ./perf probe -m ./mymodule.ko my_func
 /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
 Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
   Error: Failed to add events.

 # ./perf probe -v -m ./mymodule.ko my_func
 probe-definition(0): my_func
 symbol:my_func file:(null) line:0 offset:0 return:0 lazy:(null)
 0 arguments
 Could not open debuginfo. Try to use symbols.
 symsrc__init: build id mismatch for /home/wangnan/kmodule/mymodule.ko.
 /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
 Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
   Error: Failed to add events. Reason: No such file or directory (Code: -2)

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
---

v2 -> v3: pass dso to adjust_dso_long_name() instead of map
          because adjust_dso_long_name() doesn't use other part of map.

---
 tools/perf/util/machine.c | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 7f5071a..5781992 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -561,6 +561,24 @@ int machine__process_switch_event(struct machine *machine __maybe_unused,
 	return 0;
 }
 
+static void adjust_dso_long_name(struct dso *dso, const char *filename)
+{
+	const char *dup_filename;
+
+	if (!filename || !dso || !dso->long_name)
+		return;
+	if (dso->long_name[0] != '[')
+		return;
+	if (!strchr(filename, '/'))
+		return;
+
+	dup_filename = strdup(filename);
+	if (!dup_filename)
+		return;
+
+	dso__set_long_name(dso, filename, true);
+}
+
 struct map *machine__findnew_module_map(struct machine *machine, u64 start,
 					const char *filename)
 {
@@ -573,8 +591,15 @@ struct map *machine__findnew_module_map(struct machine *machine, u64 start,
 
 	map = map_groups__find_by_name(&machine->kmaps, MAP__FUNCTION,
 				       m.name);
-	if (map)
+	if (map) {
+		/*
+		 * If the map's dso is an offline module, give dso__load()
+		 * a chance to find the file path of that module by fixing
+		 * long_name.
+		 */
+		adjust_dso_long_name(map->dso, filename);
 		goto out;
+	}
 
 	dso = machine__findnew_module_dso(machine, &m, filename);
 	if (dso == NULL)
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278345 — Re: [PATCH v3] perf probe: Adjust dso->long_name for offline module

FromArnaldo Carvalho de Melo <acme@kernel.org>
Date2015-11-26 17:50 +0100
SubjectRe: [PATCH v3] perf probe: Adjust dso->long_name for offline module
Message-ID<qz7U6-7K3-13@gated-at.bofh.it>
In reply to#1277966
Em Thu, Nov 26, 2015 at 03:59:57AM +0000, Wang Nan escreveu:
> Something unexpected may happen if copy statically linked perf to a
> production environment:
> 
>  # ./perf probe -m ./mymodule.ko my_func
>  [mymodule] with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
>  Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
>    Error: Failed to add events.
>  # ./perf buildid-cache -a ./mymodule.ko
>  # ./perf probe -m ./mymodule.ko my_func
>  Added new event:
>    probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)
> 
>  You can now use it in all perf tools, such as:
> 
>  	perf record -e probe:my_func -aR sleep 1
> 
> Where:
> 
>  # ldd ./perf
> 	not a dynamic executable
>  # strace -e open ./perf probe -m ./mymodule.ko my_func
>  ...
>  open("/home/wangnan/kmodule/mymodule.ko", O_RDONLY) = 3
>  open("/home/wangnan/kmodule/../lib64/elfutils/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>  ...
>  open("/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>  open("/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>  open("/usr/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>  open("/usr/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>  open("[mymodule]", O_RDONLY)            = -1 ENOENT (No such file or directory)
>  open("/home/wangnan/.debug/.build-id/32/6ab42550ef3d24944f53c817533728367effeb", O_RDONLY) = -1 ENOENT (No such file or directory)
>  open("[mymodule]", O_RDONLY)            = -1 ENOENT (No such file or directory)
> 
> In the above example, probe fails before we put the module into
> buildid-cache. However, user would expect it success in both case
> because perf is able to find probe points actually.
> 
> The reason is because perf won't utilize module's full path if it
> failed to open debuginfo. In
>  convert_to_probe_trace_events ->
>  find_probe_trace_events_from_map ->
>  get_target_map ->
>  kernel_get_module_map ->
>  machine__findnew_module_map ->
>  map_groups__find_by_name
> 
> map_groups__find_by_name() is able to find the map of that module, but
> this information is found from /proc/module before it knows the real
> path of the offline module. Therefore, the map->dso->long_name is
> set to something like '[mymodule]', which prevent dso__load() find
> the real path of the module file.
> 
> In another aspect, if dso__load() can get the offline module through
> buildid cache, it can read symble table from that ko. Even if debuginfo
> is not available, 'perf probe' can success if the '.symtab' can be
> found.
> 
> This patch improves machine__findnew_module_map(): when dso->long_name
> is leading with '[' (doesn't find path of module when parsing
> /proc/modules), fixes it by dso__set_long_name(), so following
> dso__load() is possible to find the symbol table.
> 
> This patch won't interfere with buildid matching. Here is the test
> result:
> 
>  # ./perf probe -m ./mymodule.ko my_func
>  Added new event:
>    probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)
> 
>  You can now use it in all perf tools, such as:
> 
>  	perf record -e probe:my_func -aR sleep 1
> 
>  # ./perf probe -d '*'
>  Removed event: probe:my_func
>  # mv ./mymodule.{ko,.bak}
>  # mv ./moduleb.ko mymodule.ko
>  # ./perf probe -m ./mymodule.ko my_func
>  /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
>  Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
>    Error: Failed to add events.
> 
>  # ./perf probe -v -m ./mymodule.ko my_func
>  probe-definition(0): my_func
>  symbol:my_func file:(null) line:0 offset:0 return:0 lazy:(null)
>  0 arguments
>  Could not open debuginfo. Try to use symbols.
>  symsrc__init: build id mismatch for /home/wangnan/kmodule/mymodule.ko.
>  /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
>  Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
>    Error: Failed to add events. Reason: No such file or directory (Code: -2)
> 
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Zefan Li <lizefan@huawei.com>
> Cc: pi3orama@163.com
> ---
> 
> v2 -> v3: pass dso to adjust_dso_long_name() instead of map
>           because adjust_dso_long_name() doesn't use other part of map.
> 
> ---
>  tools/perf/util/machine.c | 27 ++++++++++++++++++++++++++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index 7f5071a..5781992 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -561,6 +561,24 @@ int machine__process_switch_event(struct machine *machine __maybe_unused,
>  	return 0;
>  }
>  
> +static void adjust_dso_long_name(struct dso *dso, const char *filename)

Here, to follow convention, and also to better reflect what it does,
since it deals _only_ with kernel modules, not with all dsos, I'd call
it:

static void dso__adjust_kmod_long_name(struct dso *dso, const char *filename)

It will validate if it is a long name that needs fixing, by looking at
the fist character in long_name.

I thought about dso__set_kmod_long_name() but that would imply that it
would always set it to the filename provided, but 'adjust' seems better
as it will only do it if needed, i.e. if it is still in the initial
'[name]' form.

Since this is just naming, I'll do these changes and apply as you
already addressed Masami's request that this be done in machine.c, and I
agree with that, just please take the above rationale into account for
future patches.

Thanks,

- Arnaldo

> +{
> +	const char *dup_filename;
> +
> +	if (!filename || !dso || !dso->long_name)
> +		return;
> +	if (dso->long_name[0] != '[')
> +		return;
> +	if (!strchr(filename, '/'))
> +		return;
> +
> +	dup_filename = strdup(filename);
> +	if (!dup_filename)
> +		return;
> +
> +	dso__set_long_name(dso, filename, true);
> +}
> +
>  struct map *machine__findnew_module_map(struct machine *machine, u64 start,
>  					const char *filename)
>  {
> @@ -573,8 +591,15 @@ struct map *machine__findnew_module_map(struct machine *machine, u64 start,
>  
>  	map = map_groups__find_by_name(&machine->kmaps, MAP__FUNCTION,
>  				       m.name);
> -	if (map)
> +	if (map) {
> +		/*
> +		 * If the map's dso is an offline module, give dso__load()
> +		 * a chance to find the file path of that module by fixing
> +		 * long_name.
> +		 */
> +		adjust_dso_long_name(map->dso, filename);
>  		goto out;
> +	}
>  
>  	dso = machine__findnew_module_dso(machine, &m, filename);
>  	if (dso == NULL)
> -- 
> 1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278586 — [tip:perf/core] perf machine: Adjust dso-> long_name for offline module

Fromtip-bot for Wang Nan <tipbot@zytor.com>
Date2015-11-27 08:50 +0100
Subject[tip:perf/core] perf machine: Adjust dso-> long_name for offline module
Message-ID<qzlX4-8k4-17@gated-at.bofh.it>
In reply to#1277966
Commit-ID:  c03d5184f0e92fa696e4b57f54ffc3b19a92f704
Gitweb:     http://git.kernel.org/tip/c03d5184f0e92fa696e4b57f54ffc3b19a92f704
Author:     Wang Nan <wangnan0@huawei.com>
AuthorDate: Thu, 26 Nov 2015 03:59:57 +0000
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Thu, 26 Nov 2015 13:47:43 -0300

perf machine: Adjust dso->long_name for offline module

Something unexpected may happen if copy statically linked perf to a
production environment:

  # ./perf probe -m ./mymodule.ko my_func
  [mymodule] with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
  Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
    Error: Failed to add events.
  # ./perf buildid-cache -a ./mymodule.ko
  # ./perf probe -m ./mymodule.ko my_func
  Added new event:
    probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)

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

  	perf record -e probe:my_func -aR sleep 1

Where:

  # ldd ./perf
 	not a dynamic executable
  # strace -e open ./perf probe -m ./mymodule.ko my_func
  ...
  open("/home/wangnan/kmodule/mymodule.ko", O_RDONLY) = 3
  open("/home/wangnan/kmodule/../lib64/elfutils/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  ...
  open("/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  open("/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  open("/usr/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  open("/usr/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  open("[mymodule]", O_RDONLY)            = -1 ENOENT (No such file or directory)
  open("/home/wangnan/.debug/.build-id/32/6ab42550ef3d24944f53c817533728367effeb", O_RDONLY) = -1 ENOENT (No such file or directory)
  open("[mymodule]", O_RDONLY)            = -1 ENOENT (No such file or directory)

In the above example, probe fails before we put the module into
buildid-cache. However, user would expect it success in both case
because perf is able to find probe points actually.

The reason is because perf won't utilize module's full path if it failed
to open debuginfo. In:

     convert_to_probe_trace_events ->
        find_probe_trace_events_from_map ->
            get_target_map ->
                kernel_get_module_map ->
                    machine__findnew_module_map ->
                        map_groups__find_by_name

map_groups__find_by_name() is able to find the map of that module, but
this information is found from /proc/module before it knows the real
path of the offline module. Therefore, the map->dso->long_name is set to
something like '[mymodule]', which prevent dso__load() find the real
path of the module file.

In another aspect, if dso__load() can get the offline module through
buildid cache, it can read symble table from that ko. Even if debuginfo
is not available, 'perf probe' can success if the '.symtab' can be
found.

This patch improves machine__findnew_module_map(): when dso->long_name
is leading with '[' (doesn't find path of module when parsing
/proc/modules), fixes it by dso__set_long_name(), so following
dso__load() is possible to find the symbol table.

This patch won't interfere with buildid matching. Here is the test
result:

  # ./perf probe -m ./mymodule.ko my_func
  Added new event:
    probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)

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

  	perf record -e probe:my_func -aR sleep 1

  # ./perf probe -d '*'
  Removed event: probe:my_func
  # mv ./mymodule.{ko,.bak}
  # mv ./moduleb.ko mymodule.ko
  # ./perf probe -m ./mymodule.ko my_func
  /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
  Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
    Error: Failed to add events.

  # ./perf probe -v -m ./mymodule.ko my_func
  probe-definition(0): my_func
  symbol:my_func file:(null) line:0 offset:0 return:0 lazy:(null)
  0 arguments
  Could not open debuginfo. Try to use symbols.
  symsrc__init: build id mismatch for /home/wangnan/kmodule/mymodule.ko.
  /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
  Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
    Error: Failed to add events. Reason: No such file or directory (Code: -2)

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1448510397-187965-1-git-send-email-wangnan0@huawei.com
[ Renamed adjust_dso_long_name() do dso__adjust_kmod_long_name() ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/util/machine.c | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index f0019b7..95a7f60 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -561,6 +561,24 @@ int machine__process_switch_event(struct machine *machine __maybe_unused,
 	return 0;
 }
 
+static void dso__adjust_kmod_long_name(struct dso *dso, const char *filename)
+{
+	const char *dup_filename;
+
+	if (!filename || !dso || !dso->long_name)
+		return;
+	if (dso->long_name[0] != '[')
+		return;
+	if (!strchr(filename, '/'))
+		return;
+
+	dup_filename = strdup(filename);
+	if (!dup_filename)
+		return;
+
+	dso__set_long_name(dso, filename, true);
+}
+
 struct map *machine__findnew_module_map(struct machine *machine, u64 start,
 					const char *filename)
 {
@@ -573,8 +591,15 @@ struct map *machine__findnew_module_map(struct machine *machine, u64 start,
 
 	map = map_groups__find_by_name(&machine->kmaps, MAP__FUNCTION,
 				       m.name);
-	if (map)
+	if (map) {
+		/*
+		 * If the map's dso is an offline module, give dso__load()
+		 * a chance to find the file path of that module by fixing
+		 * long_name.
+		 */
+		dso__adjust_kmod_long_name(map->dso, filename);
 		goto out;
+	}
 
 	dso = machine__findnew_module_dso(machine, &m, filename);
 	if (dso == NULL)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web