Re: ABI Compliance Checker GSoC Project

On Jun 3, 2025, at 13:23, Mankirat Singh <mankiratsingh1315(at)gmail(dot)com> wrote:

>> I don't think it's the
>> job of the tool to determine that this ABI difference is okay.
>> Ultimately that's for a human to determine,
>
> Yes, but it would be better if we could automate that thing to some
> extent, along with the development of the ABI compliance checker.

To which thing do you refer here? If I understand Álvaro correctly, it might be best to start out excluding no symbols at all, and leaving it to humans to decide whether there is an issue or not.

> 'struct ResultRelInfo at execnodes.h:450:1' changed:
> type size changed from 376 to 384 (in bytes)
> 1 data member insertion:
> 'bool ri_needLockTagTuple', at offset 376 (in bytes) at execnodes.h:597:1

Is there a way to tell that it was’t inserted at the end or into padding space?

>> I think in a first cut of this tooling, we should consider all ABI
>> changes as potentially problematic.
>
> Certainly, will do that only until I understand how to identify and
> implement some techniques for the removal of false positives.

Maybe it’s enough right now that there are some methods in the tool? But I agree that we’ll want to exclude certain patterns much sooner than later.

>> Please elaborate. Can you not write a suppression file that says
>> "ignore offset changes for ios_in_progress in ReadStream", for example?
>
> I can do that, and that's what's causing the problem. According to
> the documentation for these suppression files[1], we have to mention
> the particular symbol name we need to suppress like "ReadStream" or
> something particular like "ignore offset changes for ios_in_progress
> in ReadStream between member1 and member 2" which is humanly very hard
> to do as for sure there will be 100s of symbols in postgres like this
> which needs to be ignored in that case.

I suspect quite a few of us are comfortable with regular expressions to support something like

/offset changes for \w+ in \w+ between member\d+ and member\d+/

>>> 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.
>>
>> Ummm, are you saying that it complains about changes to unexported
>> symbols also?

This is a good question.

> This led me to another doubt, which might make things clear, that is,
> any symbol which abidiff gives in output is important to report?
> because my initial thought was that symbols exported in the binary
> created when we build postgres also contain some symbols which need to
> be suppressed because they are some postgres internal functions[2] -
> is that true?
> If it's not true, then things seem to be much sorted than before.
>
> Note - The -fvisibility=hidden flag I mentioned was on a similar note
> that when we compile postgres with this flag, it should generate
> postgres binary by removing internal symbols, but instead it gives a
> compilation error.

What’s the error? Maybe we can fix it.

Best,

David