From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1A5A13860C3F; Tue, 23 Mar 2021 12:24:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1A5A13860C3F From: "woodard at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/27635] New: abicompat doesn't handle abixml Date: Tue, 23 Mar 2021 12:24:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: 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 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 12:24:03 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27635 Bug ID: 27635 Summary: abicompat doesn't handle abixml Product: libabigail Version: unspecified Status: NEW Severity: normal Priority: P2 Component: default Assignee: dodji at redhat dot com Reporter: woodard at redhat dot com CC: libabigail at sourceware dot org Target Milestone: --- abicompat doesn't handle abixml files So for example say you want to save abixml files of some for some out of di= stro proprietary application or an out of tree kernel module and make sure that = the abicompat can verify that a change to a library doesn't impact it. You may = want to do something like: abidw foo.app > foo.abixml Then at some later time you take this foo.abixml abicompat foo.abixlm oldlib.elf newlib.elf Unfortunately right now because the undefined symbols are not stored in abi= xml files produced by abidw this can not be done directly.=20 You have to separately extract the undefined symbols and then reassociate t= hem with the symbols that are are in the abixml to be able to perform the abico= mpat test.=20 While abicompat has a way to produce the undefined symbols list by using the abicompat -u option it does not provide a way to reconsume that list and reassociate the symbols with the app to make reconstitute the interfaces between the libraries. In other words you can't do: abidw foo.app > foo.abixml abicompat -u foo.app > foo.undefsyms then at some later point: abicompat foo.abixml:foo.undefsyms oldlib.elf newlib.elf This would allow the QA department of a distro company to maintain the abix= ml of proprietary apps known to be used by customers and and then verify that changes to a library will not in fact create a problem for customers using those libraries without having to keep copies of the application and know h= ow to run them. This presents a different way of thinking about the abixml file. Previously= the abixml file was thought of as the exported decls and types which is the top surface of the ABI presented by the ELF file. This is useful for library fi= les but it is not sufficient for applications which don't necessarily export th= at much but consume quite a lot. --=20 You are receiving this mail because: You are on the CC list for the bug.=