Re: [PATCH 3/3] ir: Consider integral types of same kind and size as equivalent

[Dodji Seketeli <dodji@seketeli.org>]

Giuliano Procida <gprocida@google.com> a écrit:

> Sorry, I have to be brief...

No problem.

[...]

>> Right.  But as usual with these things (API vs ABI conformance), we try
>> to accommodate people's need as much as possible, with a preference with
>> ABI conformance when we can't ensure both at the same time.  That's what
>> we have done historically, but of course, my stance is not cast in
>> stone.  I am open to discussion and change.
>>
>> In this particular case of /C type/ program, it seems to be that the
>> programmers expect the types to be ABI compatible.
>
> I think with so much multi-architecture code about and the difficulty
> of (say) ABI
> monitoring less common architectures, detecting API changes that will be ABI
> breaks on another architecture seems like a big positive.

This is interesting.

Historically, I chose to analyse binaries rather than source code
precisely because I wanted to compare the ABIs of the binaries directly,
architecture per architecture, rather than trying to infer what API
change might incur an ABI change.  The main assumption is that we do
*HAVE* access to the actual binaries.  And what I really cared about was
actual ABI changes, not API changes.

Doing the API compatibility verification came afterwards, in a "nice to
have manner", from the request of users over time, like icing on the
cake, so to speak.  The core of what I wanted really was ABI comparison.

It's funny to see how the API side of the requirement got stronger over
time.

Anyway, I think I get your point.

[...]

>> >> Otherwise, that causes spurious type changes that lead to self
>> >> comparison change down the road.  For instance, the following command
>> >> fails:
>> >>
>> >>     $ tools/fedabipkgdiff --debug --self-compare -a --from fc36 btrfs-progs
>> >
>> > Shouldn't any tweaking of behaviour happen with abidiff rather than abidw?
>>
>>
>> I am not sure to understand the question.  This kind of adjustment of
>> what is is read from the binary typically tends to happen at the core
>> level (either DWARF reader, IR construction/transformation, comparison,
>> etc) rather at the level of a specific tool.  Am I missing something
>> from what you have in mind?
>
> The earlier the re-interpretation is, the less visible it is and the original
> information cannot be recovered.

Of course.  But keep some information all the way can be more costly
than trimming them off early, if we know we don't need them.  It's a
tradeoff that seems clear in my mind.

> Alternatively, isn't this sort of thing exactly what the suppression logic in
> abidiff is supposed to be used for?

Self-comparing the IR from a binary against it's abixml counterpart is
supposed to be done without any suppression specification applied.

OK, so here is what I am proposing.

Either I disable this thing altogether (namely, saying that int, short
int, long int and long long int are the same if the types have the same
size; note that other integral types are not touched by this) and give
up on the self-comparison check failure of the btrfs-progs package or I can
use this "abi-only-comparison" only when we do self-comparison check,
i.e, when we do abidw --abidiff and abipkgdiff --self-check.

I have a candidate patch for the later and the former is even easier to
do.

@Ben and @Giuliano, what would you prefer?

Cheers,

-- 
		Dodji