Bug 27635 - abicompat doesn't handle abixml
Summary: abicompat doesn't handle abixml
Status: RESOLVED FIXED
Alias: None
Product: libabigail
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Dodji Seketeli
URL:
Keywords:
Depends on:
Blocks: 27019
  Show dependency treegraph
 
Reported: 2021-03-23 12:24 UTC by Ben Woodard
Modified: 2022-06-08 15:45 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Woodard 2021-03-23 12:24:02 UTC
abicompat doesn't handle abixml files

So for example say you want to save abixml files of some for some out of distro 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 abixml files produced by abidw this can not be done directly. 

You have to separately extract the undefined symbols and then reassociate them with the symbols that are are in the abixml to be able to perform the abicompat test. 

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 abixml 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 how 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 files but it is not sufficient for applications which don't necessarily export that much but consume quite a lot.
Comment 1 Ben Woodard 2022-06-08 15:45:20 UTC
This bug is addressed by this commit. https://sourceware.org/pipermail/libabigail/2022q2/004405.html