Re: [lmi] perf

[Vadim Zeitlin]

On Tue, 29 Sep 2020 08:51:38 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-09-28 21:33, Vadim Zeitlin wrote:
GC> > On Mon, 28 Sep 2020 21:10:54 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> > 
GC> > [...long story of adventures and discovery snipped...]
GC> > GC> Let's try to help it find debug symbols, by copying the libraries 
into a
GC> > GC> local directory where they can do no harm [you foresee the outcome, 
but
GC> > GC> I didn't]:
GC> > 
GC> >  Yes, I should have told you about this, sorry...
GC> 
GC> There's no way you can foresee all the blind alleys I might go down.
GC> But what puzzles me is that this seems to be a GNU/Linux parallel
GC> of "DLL hell".

 IMHO not really. You're mixing 2 different systems, of course there are
going to be problems. DLL hell is about using several versions of the
system DLLs on the same system. Linux/ELF also has the soname which allows
distinguishing incompatible versions of the same DLL, which is sorely
lacking under MSW (and results in having msvcp100.dll, msvcp110.dll,
msvcp120.dll, msvcp140.dll, msvcp140_1.dll and msvcp140_2.dll in my system
directory because the name has to be used as a workaround (and as a funny
consequence now you have to skip soname corresponding to the version 13 to
avoid upsetting superstitious people)).

GC> On msw, I can avoid that problem by copying all
GC> shared libraries to the same directory as the binaries that need
GC> them (except the C runtime used by MinGW, which seems to have a
GC> special kind of extended long-term support). On GNU/Linux, is there
GC> some such sovereign remedy--a solid workaround that always works?

 Setting LD_LIBRARY_PATH does always work. The problem here is that perf on
the main system doesn't find the symbols using the paths from chroot.

GC> >  If you do have the symbols, at the very least you would be able to decode
GC> > the address manually using "addr2line -f -e 
/lib/x86_64-linux-gnu/libm.so".
GC> 
GC> addr2line: /lib/x86_64-linux-gnu/libm.so: file format not recognized

 Hmm, what is this file? It could be a linker script, I guess. I should
have written libm-2.29.so in full.

GC> > but this is mostly for curiosity, it's simpler to just bind-mount the
GC> > entire directory, I think).
GC> 
GC> Wait...do you mean bind-mount /usr/lib/ so that the chroot's
GC> directory hides the host's? Won't that probably crash the host?

 You're right, this is not going to work, I didn't think things through,
sorry. Thinking more about this again, I don't see any simple way to solve
the problem of the symbols for the system libraries.

 Maybe the simplest would actually be to install the right version of perf
inside the chroot, compiling it yourself if necessary. I haven't done this,
but it shouldn't be difficult, you'd just need the kernel headers. And you
could also build it from its source Debian package.

 Regards,
VZ

pgp_gC348Je3e.pgp
Description: PGP signature