On 2015/11/26 9:10, 平松雅巳 / HIRAMATU，MASAMI wrote:
From: Wang Nan [mailto:[email protected]]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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
