perf/urgent improvement and fix

Hi Ingo,

Please consider pulling,

- Arnaldo

Build results (some more images added):

  # perf stat dm
  alpine:3.4: Ok
  android-ndk:r12b: Ok
  centos:5: Ok
  centos:6: Ok
  centos:7: Ok
  debian:7: Ok
  debian:8: Ok
  debian:experimental: Ok
  fedora:21: Ok
  fedora:22: Ok
  fedora:23: Ok
  fedora:24: Ok
  fedora:rawhide: Ok
  mageia:5: Ok
  opensuse:13.2: Ok
  opensuse:42.1: Ok
  ubuntu:14.04.4: Ok
  ubuntu:15.10: Ok
  ubuntu:16.04: Ok
  ubuntu:16.04-x-arm64: Ok
  ubuntu:16.04-x-armhf: Ok
  ubuntu:16.04-x-powerpc64: Ok
  ubuntu:16.04-x-powerpc64el: Ok
  ubuntu:16.04-x-s390: Ok

The following changes since commit 674d2d69b14f677a771ceec4b48bfade94a0c5f1:

Merge tag 'perf-core-for-mingo-20160725' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2016-07-25 19:48:41 +0200)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-20160726

for you to fetch changes up to 203d8a4aa6edf2c19206316d439ec5dae52ce581:

perf s390: Fix 'start' address of module's map (2016-07-26 16:46:12 -0300)

----------------------------------------------------------------
perf/urgent fixes:

- Fix obtaining the 'start' address for a kernel module on s390, where .text doesn't coincides with the start of the module as reported on /proc/modules (Song Shan Gong)

- Use official ELF e_machine value for BPF objects generated via perf + LLVM when specifying BPF scriptlet in 'perf record/trace --event' (Wang Nan)

----------------------------------------------------------------
Song Shan Gong (1):
perf s390: Fix 'start' address of module's map

Wang Nan (1):
tools lib bpf: Use official ELF e_machine value

 tools/lib/bpf/libbpf.c              |  7 ++++++-
 tools/perf/arch/s390/util/Build     |  2 ++
 tools/perf/arch/s390/util/machine.c | 19 +++++++++++++++++++
 tools/perf/util/machine.c           |  8 ++++++++
 tools/perf/util/machine.h           |  1 +
 5 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 tools/perf/arch/s390/util/machine.c

From: Wang Nan <[email protected]>

New LLVM will issue newly assigned EM_BPF machine code. The new code will be propagated to glibc and libelf.

This patch introduces the new machine code to libbpf.

---
 tools/lib/bpf/libbpf.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

index 32e6b6bc6f7d..b699aea9a025 100644
@@ -37,6 +37,10 @@
 #include "libbpf.h"
 #include "bpf.h"
 
+#ifndef EM_BPF
+#define EM_BPF 247
+#endif
+
 #define __printf(a, b)	__attribute__((format(printf, a, b)))
 
 __printf(1, 2)

@@ -439,7 +443,8 @@ static int bpf_object__elf_init(struct bpf_object *obj)
 	}
 	ep = &obj->efile.ehdr;
 
-	if ((ep->e_type != ET_REL) || (ep->e_machine != 0)) {
+	/* Old LLVM set e_machine to EM_NONE */
+	if ((ep->e_type != ET_REL) || (ep->e_machine && (ep->e_machine != EM_BPF))) {
 		pr_warning("%s is not an eBPF object file\n",
 			obj->path);
 		err = -LIBBPF_ERRNO__FORMAT;

2.7.4

From: Song Shan Gong <[email protected]>

At present, when creating module's map, perf gets 'start' address by parsing '/proc/modules', but it's the module base address, it isn't the start address of the '.text' section.

In most arches, it's OK. But for s390, it places 'GOT' and 'PLT' relocations before '.text' section. So there exists an offset between module base address and '.text' section, which will incur wrong symbol resolution for modules.

Fix this bug by getting 'start' address of module's map from parsing '/sys/module/[module name]/sections/.text', not from '/proc/modules'.

---
 tools/perf/arch/s390/util/Build     |  2 ++
 tools/perf/arch/s390/util/machine.c | 19 +++++++++++++++++++
 tools/perf/util/machine.c           |  8 ++++++++
 tools/perf/util/machine.h           |  1 +
 4 files changed, 30 insertions(+)
 create mode 100644 tools/perf/arch/s390/util/machine.c

index 8a61372bb47a..5bd7b9260cc0 100644
@@ -2,3 +2,5 @@ libperf-y += header.o
 libperf-y += kvm-stat.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
+
+libperf-y += machine.o

new file mode 100644
index 000000000000..b9a95a1a8e69
@@ -0,0 +1,19 @@
+#include <unistd.h>
+#include <stdio.h>
+#include <string.h>
+#include "util.h"
+#include "machine.h"
+#include "api/fs/fs.h"
+
+int arch__fix_module_text_start(u64 *start, const char *name)
+{
+	char path[PATH_MAX];
+
+	snprintf(path, PATH_MAX, "module/%.*s/sections/.text",
+				(int)strlen(name) - 2, name + 1);
+
+	if (sysfs__read_ull(path, (unsigned long long *)start) < 0)
+		return -1;
+
+	return 0;
+}

index bc2cdbd09a25..cb6388dbdd98 100644
@@ -1093,12 +1093,20 @@ static int machine__set_modules_path(struct machine *machine)
 
 	return map_groups__set_modules_path_dir(&machine->kmaps, modules_path, 0);
 }
+int __weak arch__fix_module_text_start(u64 *start __maybe_unused,
+				const char *name __maybe_unused)
+{
+	return 0;
+}
 
 static int machine__create_module(void *arg, const char *name, u64 start)
 {
 	struct machine *machine = arg;
 	struct map *map;
 
+	if (arch__fix_module_text_start(&start, name) < 0)
+		return -1;
+
 	map = machine__findnew_module_map(machine, start, name);
 	if (map == NULL)
 		return -1;

index 41ac9cfd416b..20739f746bc4 100644
@@ -216,6 +216,7 @@ struct symbol *machine__find_kernel_function_by_name(struct machine *machine,
 
 struct map *machine__findnew_module_map(struct machine *machine, u64 start,
 					const char *filename);
+int arch__fix_module_text_start(u64 *start, const char *name);
 
 int __machine__load_kallsyms(struct machine *machine, const char *filename,
 			     enum map_type type, bool no_kcore, symbol_filter_t filter);

2.7.4

Pulled, thanks a lot Arnaldo!

Ingo