Re: [lmi] perf

[Greg Chicares]

On 2020-09-28 21:33, Vadim Zeitlin wrote:
> On Mon, 28 Sep 2020 21:10:54 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> [...long story of adventures and discovery snipped...]
> GC> Let's try to help it find debug symbols, by copying the libraries into a
> GC> local directory where they can do no harm [you foresee the outcome, but
> GC> I didn't]:
> 
>  Yes, I should have told you about this, sorry...

There's no way you can foresee all the blind alleys I might go down.
But what puzzles me is that this seems to be a GNU/Linux parallel
of "DLL hell". On msw, I can avoid that problem by copying all
shared libraries to the same directory as the binaries that need
them (except the C runtime used by MinGW, which seems to have a
special kind of extended long-term support). On GNU/Linux, is there
some such sovereign remedy--a solid workaround that always works?
If so, is the key that libm-2.29.so and libm-2.28.so are distinct
files for sub-versions 29 and 28, so they can both live in the same
directory? And does that directory really need to be /usr/lib/[arch],
or is there a valid way that I can gather all the (chroot) files in
a single (host) directory...e.g., by prefixing each command with
something like "LD_LIBRARY_PATH=:" or "LD_LIBRARY_PATH=."? If such
a goal is even possible, then would 'rpath' be a better way of
achieving it? E.g.:
  cc -shared -Wl,-soname,libm-2.29.so,-rpath,./libm-2.29.so
to make a collection of files that can be copied from the chroot
and run on the host without touching any host system directories?

> GC> And now 'perf' informs us:
> GC> 
> GC>      6.21%  lmi_cli_shared  liblmi.so                           [.] 
> AccountValue::DecrementAVProportionally
[...]
> GC>      1.97%  lmi_cli_shared  libm-2.29.so                        [.] 
> 0x000000000001b1c9
> [...]
> GC> It still doesn't find libraries like 'libm-2.29.so' above
[...]
>  First thing to check is whether you actually have debug symbols for libm
> installed? They're part of libc6-dbg package (as I've just checked), so
> you'd need to have it installed in chroot.
> 
>  If you do have the symbols, at the very least you would be able to decode
> the address manually using "addr2line -f -e /lib/x86_64-linux-gnu/libm.so".

addr2line: /lib/x86_64-linux-gnu/libm.so: file format not recognized

Maybe that just means that I don't have the debug symbols installed yet.

> GC> On the host system, we have:
> GC> 
> GC> /tmp/perf-chroot-symbols[0]#ls -l /usr/lib/x86_64-linux-gnu/libm-*
> GC> -rw-r--r-- 1 root root 1579448 May  1  2019 
> /usr/lib/x86_64-linux-gnu/libm-2.28.so
> GC> 
> GC> and how dangerous would it be if I copied the chroot's 2.29 into
> GC> the host's directory? Stop me before I do something really foolish.
> 
>  It probably won't be dangerous at all, but I don't think it will be
> actually helpful neither, as you also need the debug symbols file which is
> /usr/lib/debug/.build-id/88/5dda4b4a5cea600e7b5b98c1ad86996c8d2299.debug on
> my Buster system and something similar under Bullseye (you can use
> "readelf" or even just "file" command to find the build-id of libm-2.29.so,

All I have there is a couple 'java' things:

$ ls /usr/lib/debug/usr/lib/*
java-1.11.0-openjdk-amd64  java-11-openjdk-amd64

so I would need to install 'libc6-dbg'. But...

> but this is mostly for curiosity, it's simpler to just bind-mount the
> entire directory, I think).

Wait...do you mean bind-mount /usr/lib/ so that the chroot's
directory hides the host's? Won't that probably crash the host?

> GC> What would be better? Compile gcc-10 from sources? Last I heard,
> GC> that took days, but that was probably a couple decades ago.
> 
>  Compiling gcc is pretty straightforward nowadays and almost embarrassingly
> parallel, so I'd be surprised if it took you more than 10 minutes with your
> hardware.

Excellent.

> Compiling MinGW might be somewhat more involved, I haven't done
> it since a very long time, so I am not sure.

At this moment, I only want to be able to use 'perf' with lmi,
and a GNU/Linux build of lmi is pretty certain to have the same
performance "hotspots" as an msw build. And 'wine' always seems
to complicate things; besides, I'd much rather restrict 'wine'
to a chroot that has no web browser, even though a chroot isn't
an escape-proof "jail".

But someday it might be useful to compile MinGW-w64 gcc, especially
because its maintainers don't seem to release binaries for anything
more recent than gcc-8.