Created attachment 8973 [details] Dump files and suppressions file $ cat suppressions [suppress_function] change_kind = all $ abidiff --suppressions suppressions dump1 dump2 Functions changes summary: 0 Removed, 0 Changed, 160 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 0 Removed, 90 Added function symbols not referenced by debug info Variable symbols changes summary: 0 Removed, 2 Added variable symbols not referenced by debug info 160 Added functions: [A] 'function unity::scopes::testing::Benchmark::Result* boost::serialization::factory<unity::scopes::testing::Benchmark::Result, 0>(typedef __va_list_tag __va_list_tag*)' {_ZN5boost13serialization7factoryIN5unity6scopes7testing9Benchmark6ResultELi0EEEPT_P13__va_list_tag} ... It seems that, no matter what I put into the suppressions file (even syntax errors), the file is never used.
OK, it looks like we really need to have better documentation *and* better feedback from the sub-system that handles the suppression specifications here. > $ cat suppressions > [suppress_function] > change_kind = all So, for the suppress_function directive to work, you need to provide at least one of the following properties: label, name, name_regexp, return_type_name, return_type_name_regexp, symbol_name, symbol_name_regexp, symbol_version, symbol_version_regexp or parameter. If you just provide the change_kind = all without providing any of the above properties, the supprss_function directive is ignored. For instance, I just ran a little test here: $ abidiff test0.o test1.o Functions changes summary: 0 Removed, 0 Changed, 1 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable 1 Added function: 'function void baz()' {_Z3bazv} $ cat no-added-fns.abignore [suppress_function] # Suppress all functions that got added. These are not ABI # incompatible changes name_regexp = *. change_kind = added-function $ abidiff --suppressions no-added-fns.abignore test0.o test1.o ; echo "returned value: $?" Functions changes summary: 0 Removed, 0 Changed, 0 Added function (1 filtered out) Variables changes summary: 0 Removed, 0 Changed, 0 Added variable returned value: 0 $ So that should work for you, hopefully? Now I think we need a separate enhancement request to add better feedback about these things.
Thanks for your help! Doc improvements would be good, at least for the major cases. For niggly detailed stuff, I'd probably rely on just complaining when parsing the ini file and spit out an appropriate error message. Otherwise, the doc might get too scary. In general, better semantic checks on the suppression file would be really good. I erroneously concluded that the entire --suppressions option was dysfunctional, simply because the total lack of feedback.
> Thanks for your help! You are welcome. > Doc improvements would be good, at least for the major cases. I have just pushed a doc change that states the mandatory options at https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commit;h=0cb928083d426fc519bc6f89afc2299ab4a2a68b The web site has been updated accordingly. Now you can read at https://sourceware.org/libabigail/manual/libabigail-concepts.html#suppress-function: Note that for the [suppress_function] directive to work, at least one of the following properties must be provided: label, name, name_regexp, parameter, return_type_name, symbol_name, symbol_name_regexp, symbol_version, symbol_version_regexp. If none of the following properties are provided, then the [suppression_function] directive is simply ignored. > For niggly detailed stuff, I'd probably rely on just complaining when > parsing the ini file and spit out an appropriate error > message. Otherwise, the doc might get too scary. Indeed. We need a separate enhancement request for this. > In general, better semantic checks on the suppression file would be > really good. I erroneously concluded that the entire --suppressions > option was dysfunctional, simply because the total lack of feedback. Damn right are you.
Now that you (rightfully) filed and enhancement for checks against the ini file in bug #19608, I guess we can close this problem report. We'll track the issue there. Thank you for taking the time to report this issue!