Re: ABI Compliance Checker GSoC Project - Mailing list pgsql-hackers

Following up on this, I would really like to know and understand how I can actually differentiate between what symbols the abidiff tool outputs are considered to be causing ABI instability and what are not.

For example, in minor release 17.0 to 17.1, struct ResultRelInfo was changed by adding a new data member, causing the ABI instability.

But when I tried to compare the postgres binaries of version 17.4 and 17.5, which is supposed to have no ABI instability, I got the following output:

$ abidiff ./install/with_debug/REL_17_4/bin/postgres install/with_debug/REL_17_5/bin/postgres --leaf-changes-only --no-added-syms --show-bytes
Leaf changes summary: 2 artifacts changed
Changed leaf types summary: 2 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function (3 filtered out)
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable

'struct ReadStream at read_stream.c:109:1' changed:
  type size hasn't changed
  1 data member insertion:
    'int16 io_combine_limit', at offset 2 (in bytes) at read_stream.c:112:1
  there are data member changes:
    'int16 ios_in_progress' offset changed from 2 to 4 (in bytes) (by +2 bytes)
    'int16 queue_size' offset changed from 4 to 6 (in bytes) (by +2 bytes)
    'int16 max_pinned_buffers' offset changed from 6 to 8 (in bytes) (by +2 bytes)
    'int16 pinned_buffers' offset changed from 8 to 10 (in bytes) (by +2 bytes)
    'int16 distance' offset changed from 10 to 12 (in bytes) (by +2 bytes)
    'bool advice_enabled' offset changed from 12 to 14 (in bytes) (by +2 bytes)

'struct WalSndCtlData at walsender_private.h:91:1' changed:
  type size hasn't changed
  there are data member changes:
    name of 'WalSndCtlData::sync_standbys_defined' changed to 'WalSndCtlData::sync_standbys_status' at walsender_private.h:110:1

In the above report, the symbols ReadStream and WalSndCtlData have no type size changes.

And similarly, the following report compares the postgres binaries for versions 17.2 and 17.3:

$ abidiff ./install/with_debug/REL_17_2/bin/postgres ./install/with_debug/REL_17_3/bin/postgres --leaf-changes-only --no-added-syms --show-bytes
Leaf changes summary: 2 artifacts changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 1 Changed, 0 Added function (6 filtered out)
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable

1 function with some sub-type change:

  [C] 'function void mdtruncate(SMgrRelation, ForkNumber, BlockNumber)' at md.c:1153:1 has some sub-type changes:
    parameter 4 of type 'typedef BlockNumber' was added

'struct IndexOptInfo at pathnodes.h:1104:1' changed:
  type size hasn't changed
  there are data member changes:
    type 'void (*)(...)' of 'IndexOptInfo::amcostestimate' changed:
      pointer type changed from: 'void (*)(...)' to: 'void (*)(PlannerInfo*, IndexPath*, double, Cost*, Cost*, Selectivity*, double*, double*)'

This also gives a 1 function subtype change in mdtruncate.

I don't have much idea about the PostgreSQL internal code, but I really wanted to know how we can "classify" what exactly is a false positive for this report and should not be reported by the final ABI compliance checking tool?

I checked the suppression file for libabigail tools, but it seems not to work for the PostgreSQL case, as we need to specify each and every symbol to be ignored in the file, which is kinda not possible. And these symbols to be suppressed don't follow any common Regex as well, and the suppression file doesn't support including whole files or folders.

Secondly, we can't use the -fvisibility=hidden flag while compiling either, as it results in a failed compilation with an error.

The only thing which seems to work, as per my knowledge, is to use the nm tool with the -D flag to get the dynamic symbols list, which are more important from an ABI stability POV(as those will be used by extensions?) and grep the symbols from abidiff output. If we found nothing, then ignore the warning. Although I am unsure about this and its possible side effects...?

For e.g. - $ nm -D ./install/with_debug/REL_17_4/bin/postgres | grep WalSndCtlData 

Please correct me if I'm wrong somewhere.

Regards,

Mankirat