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

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

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

--- Comment #6 from dodji at redhat dot com ---
"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?

> 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.  In other words, we won't be
looking at the transitive closure of the binaries provided on the
command line of abidiff, but rather at their direct dependencies.

> So the "--follow-dt-needed" option could take an optional regex to filter which
> dependencies are to be considered.

Yes, the suppression specification file syntax could be augmented to
take a property that filters out the dependencies to ignore while
handling the --follow-dt-needed option.  [Note that I'd rather call the
option --follow-dependencies to avoid being specific to ELF as ABIXML
does have a similar concept too].

Would that work for you?

> I am unclear whether it may be better to *require* a filter (wrt to cpu/memory
> consumption).

I don't know first hand.  That the kind of details that can be flushed
out later after a some real world testing, I guess.

> Here is an example with how we check DPDK libraries. With this new option, I
> would focus on librte_.*\.so.* files so invoking as:
> $ abidiff --follow-dt-needed librte_ --suppr .../devtools/libabigail.abignore
> --no-added-syms --headers-dir1
> .../abi/v23.03/build-gcc-shared/usr/local/include --headers-dir2
> .../builds/main/build-gcc-shared/install/usr/local/include
> .../abi/v23.03/build-gcc-shared/usr/local/lib64/librte_eal.so
> .../builds/main/build-gcc-shared/install/usr/local/lib64/librte_eal.so

So, are you sure that librte_eal.so has ALL the split libraries
(resulting from splitting the former big library into smaller ones) as
dependencies?  I mean, this really looks like a particular case of the
general problem of being able to compare sets of ABI corpora.  Sure, I
understand how this particular use case is worth supporting (and I agree
we should support it), but in the grand scheme of things, I am wondering
if supporting /just/ this particular case makes sense.

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