Re: 'src/abg-dwarf-reader.cc:compare_dies_string_attribute_value' optimization

[Ben Woodard <woodard@redhat.com>]

Just a FYI these all completed successfully with no issues. It just took a long time. I don’t know exactly how long they took but the last time I looked they were about 400min of runtime each. 

> On Apr 12, 2022, at 7:19 PM, Ben Woodard <woodard@redhat.com> wrote:
> 
> There also appears to be some sort of performance regression. I know that these are your problem children but 
> /lib64/libmozjs-68.so.0.0.0 
> /lib64/libwebkit2gtk-4.0.so.37.56.4 
> /lib64/libgs.so.9.55 
> /lib64/libperl.so.5.34.1 
> have been running solidly for more than 3 hours. I’ll let them continue all night and see if they complete or if they are in some sort of infinite loop.

We have been doing lots of work here to really carefully understand as many ABI issues as we can and I know that this release is taking much longer than you anticipated with all the fall out from this bug and the typedef collapsing. However, we have been accumulating an ever increasing list of ABI relevant artifacts that libabigail is not detecting. It would be really nice if these could also be added to the 2.1 release:

These two should be fairly easy to add:
1) abicompat - Weak symbol replacement by a library. If a library replaces a weak symbol in the application with a strong symbol in the library, the symbols must have the same ABI signature. This is a very localized piece of code that just needs to be repeated. Right now abicompat only looks for undefined symbols in the ELF. It just needs a new ELF helper function which finds the weak symbols provided by the application and adds those to the list of functions and variables that need to be inspected in the library.
2) abicompat - Underlinked symbols in a library. Basically the same thing but instead of weak symbols or undefined symbols consider symbols who are NOTYPE.

Other things that we have uncovered which would be nice to have but are probably harder to implement:
1) RTTI - any type defined in the LSDA for exceptions must be included in the ABI analysis. If a type is thrown from a library and caught by a the application, then their types must match. These types do not necessarily appear in the list of undefined symbols in the application and so they are not considered when comparing library compatibility. Therefore, libabigail needs to go through the LSDA to find the types in the application to ensure that they are added to to the types being compared in the library.
2) Inline functions - Obviously we can’t compare that inline functions are semantically the same but we can at least make sure that the functions and the types involved with them are the same. Once again, these are not considered by abicompat because they do not appear as UNDEF symbols in the ELF. To be able to pick up these inline functions, you need to go through the DWARF callsites of both the application and the library and make sure that the function prototypes and their types which exist in both the library and the applicatoin are the same.
3) The type of TLS Thread Local Storage that a library uses must match the application. This is the difference between TLS and TLSDESC, This needs to be considered an ABI artifact. It is a little bit weird, you can probably consider it at the library level the same way that you look at SONAMEs but the type of TLS is defined at a symbol level. I have never seen someone mix objects with different kinds of TLS in one library. So I don’t know how you want to handle this. Maybe put a flag has_tls and then enumerate the flavor in the library and if the library and the application don’t have the same flavor of TLS or if two libraries have different flavors of TLS announce it. Or maybe store it in the variable where it lives in the ELF.
4) Library dependencies - When examining libraries for ABI compatibility it isn’t just the symbols used by the application itself that must be inspected, all of the other libraries that this application depends on must be considered. 
5) bidirectional compatibility - It isn’t just the undefined, weak, underlinked symbols in the application which must be compared in the libraries, it is also the symbols that are undefined in the library which are defined in the application which must be considered.

This is all just deeper processing of the ELF. I have sourceware bugs open on most of these and reproducers for several of them. I think it is very important that self-compares work and the fundamentals of type comparison are correct but we also need to not give people false notions about compatibility by ignoring things which we already know about which have ABI implications.

-ben