Re: [lmi] perf

[Greg Chicares]

On 2020-09-29 11:22, Vadim Zeitlin wrote:
> On Tue, 29 Sep 2020 08:51:38 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> 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.

/opt/lmi/src/lmi[0]$file /lib/x86_64-linux-gnu/libm.so
/lib/x86_64-linux-gnu/libm.so: ASCII text
/opt/lmi/src/lmi[0]$cat /lib/x86_64-linux-gnu/libm.so
/* GNU ld script
*/
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/x86_64-linux-gnu/libm.so.6  AS_NEEDED ( 
/usr/lib/x86_64-linux-gnu/libmvec_nonshared.a 
/lib/x86_64-linux-gnu/libmvec.so.1 ) )

Trying it anyway, without installing a debug-symbols package,
it seemed to freeze, so I hit Enter a couple times before Ctrl-C:

$addr2line -f -e /lib/x86_64-linux-gnu/libm-2.29.so 

??
??:0

??
??:0
^C

Well, 'addr2line' is never fun to use, and should be unnecessary
once I get 'perf' working properly.

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

Building from .deb sounds attractive, but it may not be
perfectly straightforward:
  
https://unix.stackexchange.com/questions/362758/building-deb-package-for-linux-perf
but I've already downloaded the right package (I installed it in
my host), and perhaps I can find a way to install that in the
chroot.

But right now I'm trapped in a morass of dependencies. Right now,
the stars are aligned so that my host has gcc-8 and so does my
production chroot, and by happy accident I really can do something
with 'perf' right now. But of course we want to upgrade to gcc-10,
which our corporate server already has, and use that for production
going forward [which means closing the window on my present ability
to use 'perf']--and that's a prerequisite for std::filesystem
migration, which is a prerequisite for dropping boost, which is
ardently desired [except perhaps for boost::regex, which is
advantageous in 'test_coding_rules' only]. But upgrading to gcc-10
while keeping my current gcc-8 production chroot intact means
creating a new chroot, which at the moment fails to build lmi
because of libxslt [which I guess is a consequence of a concurrent
'wine' upgrade that perturbs its C runtime library]. Of course,
you're about to resolve that problem, by using git-modules at
last, which is a good change, but it's still a Change with a
capital 'C'...and it calls for altering the github URLs we
depend on, which is also a good change...and so on. And then just
this morning IIRC we discussed upgrading my host to 'bullseye'....

So I figured I might spend a few hours messing around with 'perf' on
my valyuta/* branches (while the stars remain favorably aligned),
but I ran into pc-linux-gnu problems that I had already solved in
'master', and I tried merging or rebasing, and...that's a separate
message.

This is my long-winded way of saying that I appreciate the patches
you and Ilya have provided for some other things, and I won't
forget them, but I think I'll sit on them for a while longer and
move some more strings out of '.mst' files, because that's
something I know I can accomplish on my own.