linux.git/tools/lib, branch v6.2

libperf: Fix install_pkgconfig target

2022-12-16T13:04:06+00:00

Commit 47e02b94a4c98dcc ("tools lib perf: Add dependency test to install_headers")
misses the notion of $(DESTDIR_SQ) for install_pkgconfig target, which leads to
error:

  install: cannot create regular file '/usr/lib64/pkgconfig/libperf.pc': Permission denied
  make: *** [Makefile:210: install_pkgconfig] Error 1

Signed-off-by: Alexander Gordeev 
Cc: Alexander Shishkin 
Cc: Ian Rogers 
Cc: Jiri Olsa 
Cc: Josh Poimboeuf 
Cc: Mark Rutland 
Cc: Masahiro Yamada 
Cc: Namhyung Kim 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Nicolas Schier 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Tom Rix 
Cc: bpf@vger.kernel.org
Cc: llvm@lists.linux.dev
Link: http://lore.kernel.org/lkml/Y5w/cWKyb8vpNMfA@li-4a3a4a4c-28e5-11b2-a85c-a8d192c6f089.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo

Merge remote-tracking branch 'torvalds/master' into perf/core

2022-12-16T12:53:53+00:00

To resolve a trivial merge conflict with c302378bc157f6a7 ("libbpf:
Hashmap interface update to allow both long and void* keys/values"),
where a function present upstream was removed in the perf tools
development tree.

Signed-off-by: Arnaldo Carvalho de Melo

tools lib traceevent: Remove libtraceevent

2022-12-14T14:16:12+00:00

libtraceevent is now out-of-date and it is better to depend on the
system version. Remove this code that is no longer depended upon by
any builds.

Committer notes:

Removed the removed tools/lib/traceevent/ from tools/perf/MANIFEST, so
that 'make perf-tar-src-pkg' works.

Signed-off-by: Ian Rogers 
Acked-by: Steven Rostedt (VMware) 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Leo Yan 
Cc: Mark Rutland 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lore.kernel.org/lkml/20221130062935.2219247-5-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

tools lib symbol: Add dependency test to install_headers

2022-12-14T14:16:12+00:00

Compute the headers to be installed from their source headers and make
each have its own build target to install it. Using dependencies
avoids headers being reinstalled and getting a new timestamp which
then causes files that depend on the header to be rebuilt.

Signed-off-by: Ian Rogers 
Cc: Alexander Shishkin 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Josh Poimboeuf 
Cc: Mark Rutland 
Cc: Masahiro Yamada 
Cc: Namhyung Kim 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Nicolas Schier 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Tom Rix 
Cc: bpf@vger.kernel.org
Cc: llvm@lists.linux.dev
Link: https://lore.kernel.org/r/20221202045743.2639466-5-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

tools lib subcmd: Add dependency test to install_headers

2022-12-14T14:16:12+00:00

Compute the headers to be installed from their source headers and make
each have its own build target to install it. Using dependencies
avoids headers being reinstalled and getting a new timestamp which
then causes files that depend on the header to be rebuilt.

Signed-off-by: Ian Rogers 
Cc: Alexander Shishkin 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Josh Poimboeuf 
Cc: Mark Rutland 
Cc: Masahiro Yamada 
Cc: Namhyung Kim 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Nicolas Schier 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Tom Rix 
Cc: bpf@vger.kernel.org
Cc: llvm@lists.linux.dev
Link: https://lore.kernel.org/r/20221202045743.2639466-4-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

tools lib perf: Add dependency test to install_headers

2022-12-14T14:16:12+00:00

Compute the headers to be installed from their source headers and make
each have its own build target to install it. Using dependencies
avoids headers being reinstalled and getting a new timestamp which
then causes files that depend on the header to be rebuilt.

Signed-off-by: Ian Rogers 
Cc: Alexander Shishkin 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Josh Poimboeuf 
Cc: Mark Rutland 
Cc: Masahiro Yamada 
Cc: Namhyung Kim 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Nicolas Schier 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Tom Rix 
Cc: bpf@vger.kernel.org
Cc: llvm@lists.linux.dev
Link: https://lore.kernel.org/r/20221202045743.2639466-3-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

tools lib api: Add dependency test to install_headers

2022-12-14T14:16:12+00:00

Compute the headers to be installed from their source headers and make
each have its own build target to install it. Using dependencies
avoids headers being reinstalled and getting a new timestamp which
then causes files that depend on the header to be rebuilt.

Signed-off-by: Ian Rogers 
Cc: Alexander Shishkin 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Josh Poimboeuf 
Cc: Mark Rutland 
Cc: Masahiro Yamada 
Cc: Namhyung Kim 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Nicolas Schier 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Tom Rix 
Cc: bpf@vger.kernel.org
Cc: llvm@lists.linux.dev
Link: https://lore.kernel.org/r/20221202045743.2639466-2-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

libbpf: Parse usdt args without offset on x86 (e.g. 8@(%rsp))

2022-12-07T00:16:50+00:00

Parse USDT arguments like "8@(%rsp)" on x86. These are emmited by
SystemTap. The argument syntax is similar to the existing "memory
dereference case" but the offset left out as it's zero (i.e. read
the value from the address in the register). We treat it the same
as the the "memory dereference case", but set the offset to 0.

I've tested that this fixes the "unrecognized arg #N spec: 8@(%rsp).."
error I've run into when attaching to a probe with such an argument.
Attaching and reading the correct argument values works.

Something similar might be needed for the other supported
architectures.

  [0] Closes: https://github.com/libbpf/libbpf/issues/559

Signed-off-by: Timo Hunziker 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20221203123746.2160-1-timo.hunziker@eclipso.ch

libbpf: Improve usability of libbpf Makefile

2022-12-03T00:30:34+00:00

Current libbpf Makefile does not contain the help command, which
is inconvenient to use. Similar to the Makefile help command of the
perf, a help command is provided to list the commands supported by
libbpf make and the functions of the commands.

Signed-off-by: Xin Liu 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20221202081738.128513-1-liuxin350@huawei.com

libbpf: Avoid enum forward-declarations in public API in C++ mode

2022-11-30T21:56:47+00:00

C++ enum forward declarations are fundamentally not compatible with pure
C enum definitions, and so libbpf's use of `enum bpf_stats_type;`
forward declaration in libbpf/bpf.h public API header is causing C++
compilation issues.

More details can be found in [0], but it comes down to C++ supporting
enum forward declaration only with explicitly specified backing type:

  enum bpf_stats_type: int;

In C (and I believe it's a GCC extension also), such forward declaration
is simply:

  enum bpf_stats_type;

Further, in Linux UAPI this enum is defined in pure C way:

enum bpf_stats_type { BPF_STATS_RUN_TIME = 0; }

And even though in both cases backing type is int, which can be
confirmed by looking at DWARF information, for C++ compiler actual enum
definition and forward declaration are incompatible.

To eliminate this problem, for C++ mode define input argument as int,
which makes enum unnecessary in libbpf public header. This solves the
issue and as demonstrated by next patch doesn't cause any unwanted
compiler warnings, at least with default warnings setting.

  [0] https://stackoverflow.com/questions/42766839/c11-enum-forward-causes-underlying-type-mismatch
  [1] Closes: https://github.com/libbpf/libbpf/issues/249

Signed-off-by: Andrii Nakryiko 
Signed-off-by: Daniel Borkmann 
Link: https://lore.kernel.org/bpf/20221130200013.2997831-1-andrii@kernel.org