Re: [lmi] perf

[Vadim Zeitlin]

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...

GC> And now 'perf' informs us:
GC> 
GC>      6.21%  lmi_cli_shared  liblmi.so                           [.] 
AccountValue::DecrementAVProportionally
GC>      5.02%  lmi_cli_shared  liblmi.so                           [.] 
Irc7702A::DetermineLowestBft
GC>      4.57%  lmi_cli_shared  liblmi.so                           [.] 
AccountValue::TxSetDeathBft
GC>      2.83%  lmi_cli_shared  liblmi.so                           [.] 
AccountValue::ChangeSpecAmtBy
GC>      2.76%  lmi_cli_shared  liblmi.so                           [.] 
AccountValue::TxCreditInt
GC>      2.60%  lmi_cli_shared  liblmi.so                           [.] 
AccountValue::SurrChg
GC>      1.98%  lmi_cli_shared  liblmi.so                           [.] 
AccountValue::DoMonthDR
GC>      1.97%  lmi_cli_shared  libm-2.29.so                        [.] 
0x000000000001b1c9
[...]
GC> It still doesn't find libraries like 'libm-2.29.so' above (but we can
GC> assume 0x000000000001b1c9 must be some transcendental like log1p()).

 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".

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

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. Compiling MinGW might be somewhat more involved, I haven't done
it since a very long time, so I am not sure.

GC> Or just upgrade my host to 'bullseye', though blind faith is not
GC> in my nature?

 I think dist-upgrading to Bullseye is fine. Of course, I'm advising you to
do something that I don't do myself, but I'm very conservative because I'm
mostly running Debian on servers which should really remain as stable as
possible. For a desktop/development machine I think even running Sid is a
pretty reasonable proposition and Bullseye should be just fine.

 Regards,
VZ

pgpt2yC3VLylQ.pgp
Description: PGP signature