Re: abi-compliance-checker

Hi,

On 2023-06-06 18:30:38 +0200, Peter Eisentraut wrote:
> On 30.05.23 06:32, Peter Eisentraut wrote:
> > I think the way to use this would be to compute the ABI for the .0
> > release (or rc1 or something like that) and commit it into the tree. And
> > then compute the current ABI and compare that against the recorded base
> > ABI.
> > 
> > Here is the workflow:
> > 
> > # build REL_11_0
> > abidw src/backend/postgres > src/tools/postgres-abi-REL_11_0.xml
> > # build REL_11_20
> > abidw src/backend/postgres > src/tools/postgres-abi.xml
> > abidiff --no-added-syms src/tools/postgres-abi-REL_11_0.xml
> > src/tools/postgres-abi.xml
> 
> Here is a demo patch that implements this.
> 
> Right now, I have only added support for libpq and postgres.  For
> completeness, the ecpg libraries should be covered as well.

I think plpgsql would also be good to include, due to things like plpgsql
debuggers.


> * Different Linux distributions produce slightly different ABI reports. In
> some cases, symbols like 'optarg@GLIBC_2.17' leak out.

Hm, that's somewhat annoying.


> * PostgreSQL compilation options affect the exposed ABI.  This is perhaps
> expected to some degree, but there are some curious details.
> 
> * For example, --enable-cassert exposes additional symbols, and it's maybe
> not impossible for those to leak into an extension.

They *definitely* leak into extensions. A single Assert() in an extension or
use of an inline function or macro with an Assertion suffices to end up with a
reference to ExceptionalCondition.



> diff --git a/src/interfaces/libpq/libpq.base.abi.xml b/src/interfaces/libpq/libpq.base.abi.xml
> new file mode 100644
> index 0000000000..691bf192af
> --- /dev/null
> +++ b/src/interfaces/libpq/libpq.base.abi.xml
> @@ -0,0 +1,2634 @@
> +<abi-corpus path='src/interfaces/libpq/libpq.so.5.16' soname='libpq.so.5'>
> +  <elf-function-symbols>
> +    <elf-symbol name='PQbackendPID' type='func-type' binding='global-binding' visibility='default-visibility'
is-defined='yes'/>
> +    <elf-symbol name='PQbinaryTuples' type='func-type' binding='global-binding' visibility='default-visibility'
is-defined='yes'/>
> +    <elf-symbol name='PQcancel' type='func-type' binding='global-binding' visibility='default-visibility'
is-defined='yes'/>
> [...]
> +    <elf-symbol name='termPQExpBuffer' type='func-type' binding='global-binding' visibility='default-visibility'
is-defined='yes'/>
> +  </elf-function-symbols>

This seems somewhat painful in its verbosity. We also effectively already have
it in the tree, in src/interfaces/libpq/exports.txt. But I guess that's
somewhat inevitable :/

It sounds we are planning to mostly rely on CI for this, perhaps we should
rely on an artifact from a prior build for a major version + specific task,
instead of committing this to source? That'd automatically take care of
differences in ABI across different platforms etc.

If we want to commit something to the tree, I think we need a fairly
complicated "fingerprint" to avoid false positives. OS, OS version, configure
options, compiler, compiler version at least?


> +  <abi-instr version='1.0' address-size='64' path='../src/common/encnames.c' language='LANG_C99'>
> +    <array-type-def dimensions='1' type-id='c8dedbef' size-in-bits='5376' id='752c85d9'>
> +      <subrange length='42' type-id='7359adad' id='cb7c937f'/>
> +    </array-type-def>
> +    <array-type-def dimensions='1' type-id='c8dedbef' size-in-bits='infinite' id='ac835593'>
> +      <subrange length='infinite' id='031f2035'/>
> +    </array-type-def>
> +    <array-type-def dimensions='1' type-id='56ef96d7' size-in-bits='5376' id='728d2ee1'>
> +      <subrange length='42' type-id='7359adad' id='cb7c937f'/>
> +    </array-type-def>
> +    <array-type-def dimensions='1' type-id='56ef96d7' size-in-bits='infinite' id='a01b33bb'>
> +      <subrange length='infinite' id='031f2035'/>
> +    </array-type-def>
> +    <typedef-decl name='pg_enc2name' type-id='79f06fd8' id='7a4268c7'/>
> +    <class-decl name='pg_enc2name' size-in-bits='128' is-struct='yes' visibility='default' id='79f06fd8'>
> +      <data-member access='public' layout-offset-in-bits='0'>
> +        <var-decl name='name' type-id='80f4b756' visibility='default'/>
> +      </data-member>
> +      <data-member access='public' layout-offset-in-bits='64'>
> +        <var-decl name='encoding' type-id='66325df6' visibility='default'/>
> +      </data-member>
> +    </class-decl>
> +    <typedef-decl name='pg_enc' type-id='ea65169a' id='66325df6'/>
> +    <enum-decl name='pg_enc' id='ea65169a'>
> +      <underlying-type type-id='9cac1fee'/>

Hm - why is all of this stuff even ending up in the external ABI? It should
all be internal, unless I am missing something?

I might be looking the wrong way, but to me it sure looks like none of that
ends up being externally visible?


Greetings,

Andres Freund