From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 342243882AEF; Mon, 5 Jun 2023 16:53:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 342243882AEF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1685983996; bh=gGb9hh9rd9Qu8Xo5eyUnm9yP4EsbChAoGrtTbjQ7ARk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n1q7QhyU6PRGgZKgO2IJ7gm1JB/0u+ymA7awo7vHatAm5lyMh+VQXDor50kjgDqCJ AQKVbaIUhgsCLvSCeriylYwkzhCwEh9kK13kripqAOJWFha99xy6iakQYfgm7bnetm lEI7fW3NIT/KozK0Mw5XsMRRskZ2KRV9Z0vRGDAA= From: "woodard at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/30034] [libabigail] Handle library splitting Date: Mon, 05 Jun 2023 16:53:16 +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: woodard 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 #7 from Ben Woodard --- (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? 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 fi= nd 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. >=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.=20 No!!!!! Let's do the complete closure of needed libraries.=20 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 provid= es 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.=20 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' "=20 The problem is that some of our apps have as many as 1200 libraries. Consid= er: 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 us= ed interfaces were computed inside of libabigail. --=20 You are receiving this mail because: You are on the CC list for the bug.=