From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 512E7385841C; Tue, 6 Jun 2023 07:28:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 512E7385841C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1686036510; bh=ATuKQkRFuctUEbzLaPFFpVLwU3DepMhad27ha9r5lrA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aj1K+XXbycg4Le9KItdFiEMWKePt4c0jcIn2888i0fHJZohBi6xaMckL9oyvPAPN0 L3x+Gg1Eae2226sIaoHAWP9mrX4EC9qcgU8UhQeAznJSiQ8kZBPiiSM9d1lTLYvygI s27KjRUuAyo5h/DkY0v0pDu10S2wDDaqyzTUzEQY= From: "david.marchand at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/30034] [libabigail] Handle library splitting Date: Tue, 06 Jun 2023 07:28:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: david.marchand at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30034 --- Comment #8 from David Marchand --- (In reply to dodji from comment #6) > "david.marchand at redhat dot com" > writes: >=20 > [...] >=20 > > Asking for a abidiff on this librte_eal.so library file would make liba= bigail > > parse libm.so.6, libnuma.so.1 etc.... >=20 > Where would libabigail find those (dependant) libraries? I was thinking of the DT_NEEDED entries in the dynamic section of an elf binary. >=20 > > There may be a concern with recursivity, because parsing the dependenci= es of > > dependencies could become troublesome and consume a lot of cpu/memory. >=20 > 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. >=20 > > So the "--follow-dt-needed" option could take an optional regex to filt= er which > > dependencies are to be considered. >=20 > 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]. >=20 > 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. >=20 > > I am unclear whether it may be better to *require* a filter (wrt to cpu= /memory > > consumption). >=20 > 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. >=20 > > Here is an example with how we check DPDK libraries. With this new opti= on, I > > would focus on librte_.*\.so.* files so invoking as: > > $ abidiff --follow-dt-needed librte_ --suppr .../devtools/libabigail.ab= ignore > > --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 >=20 > 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=