Support suppressing data members inserted right before flexible array members (was Re: abidiff improvements for kernel UAPI checker)

[Dodji Seketeli <dodji@seketeli.org>]

Hello,

John Moon <quic_johmoo@quicinc.com> a écrit:

[...]

> To summarize, here are the four usecases we have so far and plans to
> address them:

[...]

> 3. Flex array expansion
>    - Not sure how to detect/suppress this condition
>    - Flex arrays can only be at the ends of structs, so we just need
>      to make sure new struct members come "second to last"

So, I have a patch to support this case.

It's in the branch https://sourceware.org/git/?p=libabigail.git;a=shortlog;h=refs/heads/users/dodji/fam-suppr.

The commit itself is https://sourceware.org/git/?p=libabigail.git;a=commit;h=e609f46734b07b551c1b3dbc1eeb2cea61c4ba34

Here is what the commit log says:

    Consider this code example:

        $ cat test-v0.c
         1	struct foo
         2	{
         3	  int member0;
         4	  char pad[]; /* <-- flexible array member.  */
         5	};
         6
         7	void
         8	foo(struct foo * p __attribute__((unused)))
         9	{
        10	}
        $

    Consider this new version of the code where a data member has been
    added right before the flexible array member:

        $ cat -n test-v1.c
         1	struct foo
         2	{
         3	  int member0;
         4	  char member1; /*<-- added member.  */
         5	  char pad[]; /* <-- flexible array member.  */
         6	};
         7
         8	void
         9	foo(struct foo * p __attribute__((unused)))
        10	{
        11	}
        $

    Here is what abidiff reports about the change:

        $ abidiff test-v0.o test-v1.o || echo "returned value: $?"
        Functions changes summary: 0 Removed, 1 Changed, 0 Added function
        Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

        1 function with some indirect sub-type change:

          [C] 'function void foo(foo*)' at test-v0.c:8:1 has some indirect sub-type changes:
            parameter 1 of type 'foo*' has sub-type changes:
              in pointed to type 'struct foo' at test-v1.c:1:1:
                type size changed from 32 to 64 (in bits)
                1 data member insertion:
                  'char member1', at offset 32 (in bits) at test-v1.c:4:1
                1 data member change:
                  'char pad[]' offset changed from 32 to 40 (in bits) (by +8 bits)

        returned value: 4
        $

    This patch allows users to suppress this change report using a new
    property value to the "has_data_member_inserted_at" property of the
    [suppress_type] directive.  The resulting suppression specification
    reads:

        $ cat -n foo.suppr
             1	[suppress_type]
             2	 type_kind = struct
             3       name = foo
             4	 has_data_member_inserted_at = offset_of_flexible_array_data_member
             5	 has_size_change = yes
        $

    With this suppression specification the previous command now gives:

        $ abidiff --suppr foo.suppr test-v0.o test-v1.o && echo "returned value: $?"
        Functions changes summary: 0 Removed, 0 Changed (1 filtered out), 0 Added function
        Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

        returned value: 0
        $

I hope this is close enough to what we expect.

If after testing and reviewing this patch it's good enough for you,
please let me know so that I can fold it into the WIP branch of the
"UAPI checker support" at
https://sourceware.org/git/?p=libabigail.git;a=shortlog;h=refs/heads/users/dodji/check-uapi-support.


Please note that I have filed a bug to track the progress of this
overall "check-uapi-support" effort at
https://sourceware.org/bugzilla/show_bug.cgi?id=30931.  Feel free to
follow that bug there.  You can reply to the bugzilla's emails using
your mail user agent.

> 4. Anonymous enums
>    - Not sure how to associate these enums when diffing since their
>      "made up" names don't always match before/after a patch.

As I said in an other email, this task led to the patch set
https://inbox.sourceware.org/libabigail/87r0mapspt.fsf@redhat.com/ which
is in the branch
https://sourceware.org/git/?p=libabigail.git;a=shortlog;h=refs/heads/users/dodji/better-anon-enums.
I am waiting for your feedback to fold that patch set into the WIP
branch "check-uapi-support".

> I can try tackling items 1 and 2 if you'd like - just let me know! For
> items 3 and 4, can we work up a path forward?

[...]

Hopefully things are moving somewhat now :-)

Cheers,

-- 
		Dodji