[Bug default/30034] [libabigail] Handle library splitting

["woodard at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30034

--- Comment #7 from Ben Woodard <woodard at redhat dot com> ---
(In reply to dodji from comment #6)
> "david.marchand at redhat dot com" <sourceware-bugzilla@sourceware.org>
> writes:
> 
> [...]
> 
> > Asking for a abidiff on this librte_eal.so library file would make libabigail
> > parse libm.so.6, libnuma.so.1 etc....
> 
> Where would libabigail find those (dependant) libraries?

Each ELF file optionally has a list of DT_NEEDED. So what we are asking for is
for libabigail to read the DT_NEEDED entries and use logic like ld.so to find
those libraries and then load them into the corpus group along with their
library dependencies. This is of course a recursive operation.

In a prototype that I was doing for 27514, rather than trying to imperfectly
implement ld.so's dependency resolution behavior, I reused the environment
variables used by the /usr/bin/ldd script to make ld.so generate the list of
dependencies for me. Then I just parsed the output. (I do believe that ld.so
should have a C tools interface which would do the same thing but this
currently doesn't exist in the current glibc)

If you would like, I can dig the old prototype code for this out of my git
tree.

> 
> > There may be a concern with recursivity, because parsing the dependencies of
> > dependencies could become troublesome and consume a lot of cpu/memory.
> 
> We could limit (by default) the dependant libraries to those that are
> dependencies of the libraries provided on the command line.  E.g, the
> dependencies of libm.so.6 would be ignored. 

No!!!!!
Let's do the complete closure of needed libraries. 
This creates so many problems for us that we basically haven't been able to use
libabigail for its intended purpose. I believe the abicompat example provides
the clearest example of how counter intuitive the current behavior is.

app requires lib1 and lib2

We want to know if a new version of lib1 is compatible with app. Let's call
this lib1'

to do this the expected behavior is:

abicompat app lib1 lib1'

The problem is app only makes use of a few functions in lib1. However, lib2
makes extensive use of lib1's interfaces. 

If the changes in lib1 do not affect the functions called by app then
"abicompat app lib1 lib1' " will give a false sense of compatibility.
Arguably the fix for this problem is to do the recursive expansion of the
needed library space outside of libabigail. In this case it would be:
"abicompat lib2 lib1 lib1' " 

The problem is that some of our apps have as many as 1200 libraries. Consider:
https://computing.llnl.gov/sites/default/files/2021-03/LBANN%20dependencies%20-%20small%20for%20Word.png
which is one of our apps. This ends up being an almost factorial expansion.
With the repeated parsing of each ELF file's DWARF or even abixml, turning this
into a script takes vastly more time than if the complete closure of the used
interfaces were computed inside of libabigail.

-- 
You are receiving this mail because:
You are on the CC list for the bug.