pahole and libdwarves linking/versioning issues

* pahole and libdwarves linking/versioning issues
@ 2020-11-11  0:14 Andrii Nakryiko
  2020-11-11  0:28 ` Arnaldo
  2020-11-13 11:45 ` Arnaldo Carvalho de Melo
  0 siblings, 2 replies; 4+ messages in thread
From: Andrii Nakryiko @ 2020-11-11  0:14 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, dwarves
  Cc: Alexei Starovoitov, Kernel Team, Roman Gushchin

Hey Arnaldo,

We use pahole pretty extensively here at Facebook, as you might
imagine, given it's a required tool to compile Linux kernel with BTF.

There are a few problems we periodically run into, all of which seems
to be related to the fact that pahole is just a thin wrapper binary on
top of libdwarves shared library.

One very common problem is when we upgrade the dwarves package from
one minor version to another one. Typically people would do

yum upgrade dwarves

And that would succeed to update the dwarves package (say 1.13 to
1.16). But when you run

pahole --version

You'll still see 1.13 (and still have 1.13 functionality, of
course)... So what happens is that pahole *the binary* was updated,
but libdwarves1 package, which is a dependency of dwarves package,
wasn't updated. And the actual version string all pretty much all of
the functionality is coming from libdwarves1. So users have to

yum upgrade libdwarves1

explicitly. Which is, of course, not an obvious and frustrating experience.

Also, whenever pahole is using some new API from libdwarves and
libdwarves is outdated, that results in spectacular failure during
dynamic linking time. Which makes sense because libdwarves doesn't
maintain API stability per se and is supposed to match 1:1 w/ pahole
version. But it all causes real logistics issues.

So I have a few questions:
1. Is there anything on the RPM spec side that could be done to
trigger libdwarves1 update when dwarves is updated and keep them in
sync down to the minor version?
2. If not, can we add an option of statically linking libdwarves into
pahole and other tools? That would eliminate all the problems
altogether at the expense of a pretty negligible slight increase in
the binary sizes.

Thanks!

-- Andrii

^ permalink raw reply	[flat|nested] 4+ messages in thread