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

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

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

--- Comment #8 from David Marchand <david.marchand 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?

I was thinking of the DT_NEEDED entries in the dynamic section of an elf
binary.


> 
> > 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 bad at naming and I only know elfs and dwarves creatures :-).

If you can make this available for other binary formats, then yes, a more
generic name like what you propose looks better.


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

Yes.


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

If EAL does not have all dependencies listed, that would break ABI for
applications that are linked against and only knows of this library.

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