release: Checking binary compatibility

[real-or-random]

When looking into binary compatibility (see #1055, #964), I found this nice website which describes best practices and open source tools for checking binary compatibility: https://abi-laboratory.pro This may be something to look into after the first release (but maybe before the second release).

See for example the report for Botan, which by the way doesn't provide binary compatibility across versions at all.

[hebasto]

FWIW, here is what I've got for the recent releases:

• API compatibility report for the libsecp256k1.so object between 0.2.0 and 0.3.0 versions on x86_64
• API compatibility report for the libsecp256k1.so object between 0.3.0 and 0.3.1 versions on x86_64

UPD.
For 0.3.0 --> 0.3.1:

• "The parameter tweak32 became passed in rbp register instead of r13." in secp256k1_ec_seckey_tweak_add () is caused by the 4a496a3 commit from ct: Use volatile "trick" in all fe/scalar cmov implementations #1257.
• "The parameter seckey became passed in rbx register instead of rbp." in secp256k1_ec_seckey_tweak_mul() can be avoided if compiled with -fno-omit-frame-pointer.

[sipa]

@hebasto I don't understand how that commit can have any effect on the public ABI.

[hebasto]

@hebasto I don't understand how that commit can have any effect on the public ABI.

Neither do I. That was reported by the tool. Maybe a false positive report?

[sipa]

In fact, both claimed versions sound incorrect. The third (tweak32) argument on x86_64 calling convention should be passed in the rdx register.

[hebasto]

No issues with gcc-10:

• v0.2.0 --> v0.3.0
• v0.3.0 --> v0.3.1

[real-or-random]

Interestingly, the dumps generated with gcc 10 don't have any "Reg"(ister) entries in their json file, whereas the dumps generated with gcc 11 list registers for some arguments...

Maybe open an issue with the tool?

[hebasto]

Interestingly, the dumps generated with gcc 10 don't have any "Reg"(ister) entries in their json file, whereas the dumps generated with gcc 11 list registers for some arguments...

Maybe open an issue with the tool?

The issue has been solved by forcing DWARF v4.