[lmi] Compiling linux-perf [Was: linux-perf in chroot via .deb abuse]

[Greg Chicares]

[...no action required: this just documents file 'gwc/perf_static.sh'
on the searchable email record...]

On 10/3/20 4:49 PM, Greg Chicares wrote:

[...snip discussion of brute-force approaches...]

> This way seems smarter:
> 
> http://www.brendangregg.com/perf.html#Building
> 
> | 10.1. Static Builds
> | 
> | I've sometimes done this so that I have a single perf binary that can be
> | copied into Docker containers for execution. Steps, given the Linux source:
> |
> | cd tools/perf
> | vi Makefile.perf
> |   LDFLAGS=-static
> | make clean; make

I tried that, but it failed:

# apt-get install linux-source
# pushd /usr/src
  // redirect because output is about 64K lines
# tar xvf /usr/src/linux-source-* 2>&1 |less
  // I really did type '*', then hit <Tab>
  // I have only one version of linux-source, which expanded to:
# tar xvf /usr/src/linux-source-4.19.tar.xz  2>&1 |less
# pushd   /usr/src/linux-source-4.19/tools/perf
# make clean; make EXTRA_LDFLAGS=-static 2>&1 |less

Here's what happens:

--8<----8<----8<----8<----8<----8<----8<----8<--
In file included from util/evlist.h:15,
                 from util/evsel.c:30:
util/evsel.c: In function ‘perf_evsel__exit’:
util/util.h:25:28: error: passing argument 1 of ‘free’ discards ‘const’ 
qualifier from pointer target type [-Werror=discarded-qualifiers]
 #define zfree(ptr) ({ free(*ptr); *ptr = NULL; })
util/evsel.c:1293:2: note: in expansion of macro ‘zfree’
  zfree(&evsel->pmu_name);
  ^~~~~
In file included from 
/usr/src/linux-source-4.19/tools/perf/arch/x86/include/perf_regs.h:5,
                 from util/perf_regs.h:27,
                 from util/event.h:11,
                 from util/callchain.h:8,
                 from util/evsel.c:26:
/usr/include/stdlib.h:563:25: note: expected ‘void *’ but argument is of type 
‘const char *’
 extern void free (void *__ptr) __THROW;
                   ~~~~~~^~~~~
-->8---->8---->8---->8---->8---->8---->8---->8--

My compilation errors seem to be the same as those in these two reports:
  https://lkml.org/lkml/2020/9/29/2330
  https://lkml.org/lkml/2020/9/30/1024
and again in these two:
  https://lkml.org/lkml/2020/9/29/1776
  https://lkml.org/lkml/2020/9/29/1980
Explanation from the second of those four lmkl citations:

| [...] The culprit is commit d22b67e7dae9 ("perf parse-events: Fix 3
| use after frees found with clang ASAN"). That is not a problem upstream 
because
| of commit 7f7c536f23e6af ("tools lib: Adopt zalloc()/zfree() from 
tools/perf"),
| but that is just hiding a problem with commit d22b67e7dae9 (which assigns a
| pointer allocated with strdup() to a const * and then frees that const *). 

One option would be to (enlarge my disk partition and then)
download the kernel's git repository, and rewind it back to the
last commit before the "culprit" commit identified above. But
that might be foredoomed: I imagine that debian patches the
kernels it distributes, and I'd be ignoring their patches if I
cloned the upstream repository. [Perhaps upgrading the kernel
here would provide a fixed version; I didn't try that.]

It's more expeditious just to disable the offending warning:

# make clean; make EXTRA_LDFLAGS=-static EXTRA_CFLAGS=-Wno-discarded-qualifiers 
2>&1 |less

However, I don't seem to get the purely static 'perf' that I'd hoped for:

/usr/src/linux-source-4.19/tools/perf[1]#ldd perf
        linux-vdso.so.1 (0x00007ffc570eb000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x00007f72718e4000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f72718da000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7271757000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7271752000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7271591000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7271e55000)

though that doesn't seem to matter--after hard-linking that 'perf'
to make it available in a chroot, this command works as intended,
without adding the path to the above dependencies to $LD_LIBRARY_PATH:

LD_LIBRARY_PATH=.:/opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib/ 
/srv/cache_for_lmi/perf_static/perf record --call-graph lbr ./lmi_cli_shared 
--accept --data_path=/opt/lmi/data --selftest

File 'gwc/perf_static.sh', added by lmi commit 9bc1f544a4a6c4,
summarizes these instructions (but without the rationale above),
and goes on to explain that the resulting static binary works
well for 'perf record' but not for 'perf report':

# LD_LIBRARY_PATH=.:/srv/cache_for_lmi/perf_static 
/srv/cache_for_lmi/perf_static/perf report
#
#    34.35%     0.00%  lmi_cli_shared  liblmi.so              [.] 
0x00007f58de18d8e9
#            |
#            ---0x7f58de18d8e9
#               |
#               |--28.65%--0x7f58de222bce
#
# No runtime error is reported, but the customary text-mode interface
# is not offered. This static 'perf' generates a valid 'perf.data'
# output file, which can be viewed with the 'perf_static.sh' variant
# of perf in the chroot (which then does present the customary text-
# mode interface and does decode symbols).