[Bug default/27635] New: abicompat doesn't handle abixml

["woodard at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27635

            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 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.