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 @@
> +
> +  
> +    
> +    
> +    
> [...]
> +    
> +  

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?


> +  
> +    
> +      
> +    
> +    
> +      
> +    
> +    
> +      
> +    
> +    
> +      
> +    
> +    
> +    
> +      
> +        
> +      
> +      
> +        
> +      
> +    
> +    
> +    
> +      

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