From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B8649392AC33; Mon, 5 Jun 2023 15:36:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B8649392AC33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1685979411; bh=BAVvbCnowtm5ImBDeI+QrN06KKMJ1hPV2FDXBMOSp/w=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nJe+hZiNqNETDr0wXz8s/Rjbk1Jl37DjnMnxQB5WrkwNq8eBdmhAa8xv3LfzETosH oBzEPnRQY3QVz9RhCmqESeJ0V7UTVHJW9BsarIzeipC+O6F6piBcPeXBbCO57EU5LT mjQ7T8OzzkM2NlS4/sFuYLbZbuuUBwtVdPTYrhRY= From: "dodji at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/30034] [libabigail] Handle library splitting Date: Mon, 05 Jun 2023 15:36:51 +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: dodji 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 #6 from dodji at redhat dot com --- "david.marchand at redhat dot com" writes: [...] > Asking for a abidiff on this librte_eal.so library file would make libabi= gail > 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/m= emory > 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.abig= nore > --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. --=20 You are receiving this mail because: You are on the CC list for the bug.=