Re: [lmi] perf

[Vadim Zeitlin]

On Sat, 26 Sep 2020 23:14:21 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> My normal user doesn't have CAP_SYS_ADMIN. Apparently if you have
GC> that, you're almost root anyway, so I'm reluctant to give myself
GC> that privilege--at least when I become root, I'm aware that I need
GC> to be especially careful. Do you use root, or grant your normal
GC> user CAP_SYS_ADMIN, or run 'perf' in some other way?

 I just do what, I think, it told me to do, once I've tried using it
unsuccessfully, i.e. set kernel.perf_event_paranoid kernel parameter to 0
or -1 depending on my current actual level of paranoia. This can, of
course, be done temporarily, if you run perf only episodically.

 FWIW I definitely don't run perf as root -- not because I don't trust perf
itself, but because I don't trust my own programs, that would also run as
root then.

GC> I couldn't easily install 'linux-perf' in the out-of-date chroot
GC> that I'm still using for production, due to conflicts in its
GC> required components, and I don't want to update it because I'm
GC> using it for production (and the MinGW-w64-gcc version would
GC> change to something we're not using in production yet). I had
GC> the seemingly brilliant idea of running 'perf' in my host
GC> (after installing it successfully there) to profile a binary
GC> in a chroot:
GC> 
GC> lmipath=/srv/chroot/bullseye0/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship; \
GC>  LD_LIBRARY_PATH=$lmipath; \
GC>  $lmipath/lmi_cli_shared --accept --data_path=/opt/lmi/data --selftest
GC> 
GC> However:
GC> 
GC> 
/srv/chroot/bullseye0/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/lmi_cli_shared:
 /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found 
(required by 
/srv/chroot/bullseye0/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/lmi_cli_shared)
GC> 
GC> 
/srv/chroot/bullseye0/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/lmi_cli_shared:
 /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by 
/srv/chroot/bullseye0/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/liblmi.so)
GC> 
GC> 
/srv/chroot/bullseye0/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/lmi_cli_shared:
 /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found 
(required by 
/srv/chroot/bullseye0/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/liblmi.so)
GC> 
GC> so I guess I'd need to include more chroot stuff in LD_LIBRARY_PATH:
GC> 
GC> lmipath=/srv/chroot/bullseye0/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship; 
LD_LIBRARY_PATH=$lmipath:/srv/chroot/bullseye0/lib/x86_64-linux-gnu/ ; 
$lmipath/lmi_cli_shared --accept --data_path=/opt/lmi/data --selftest
GC> 
GC> zsh: segmentation fault  $lmipath/lmi_cli_shared --accept 
--data_path=/opt/lmi/data --selftest
GC> 
GC> Well, that's frustrating. That binary runs successfully in the chroot.

 I don't really know what's going on here, but trying to run a binary from
chroot outside of chroot just seems weird. OTOH I still think you ought to
be able to run "perf record schroot -c bullseye0 /path/to/lmi_cli_shared"
or something like this, shouldn't you?

GC> Instead of trying to deal with these problems, I'll just create a new
GC> chroot (including 'perf').

 Note that perf version must correspond to the kernel version, so you can
only use it inside chroot if it uses the same kernel packages as the main
system, which is usually _not_ the case -- unless you install the same
system that you're already using inside a chroot, which is definitely
possible, but doesn't seem really necessary.

 Regards,
VZ

pgp0hObZsGuyi.pgp
Description: PGP signature