Re: ABI Compliance Checker GSoC Project

Thanks for the introduction :D

On Tue, 3 Jun 2025 at 00:36, David E. Wheeler <david(at)justatheory(dot)com> wrote:

> Since the work naturally gets into what’s considered a public API and
> what’s not, we feel that hackers is the best place to ask questions about
> bits to include and exclude, as well as other questions related to
> configuration settings, etc., so please watch for those. I hope you all
> will help Mankirat to quickly learn what’s what, figure out how it goes
> together, and make it a reality!
>
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