[PATCH v2 0/4] more replacement of zero length array

[David Marchand]

On Tue, Feb 13, 2024 at 8:20 PM Tyler Retzlaff
<roretzla at linux.microsoft.com> wrote:
>
> On Tue, Feb 13, 2024 at 02:14:28PM +0100, David Marchand wrote:
> > On Mon, Feb 12, 2024 at 11:36 PM Tyler Retzlaff
> > <roretzla at linux.microsoft.com> wrote:
> > >
> > > Replace some missed zero length arrays not captured in the
> > > original series.
> > > https://patchwork.dpdk.org/project/dpdk/list/?series=30410&state=*
> > >
> > > Zero length arrays are a GNU extension that has been
> > > superseded by flex arrays.
> > >
> > > https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> > >
> > > v2:
> > >     * added additional patches for fib & pipeline libs.
> > >       series-acks have been placed only against original
> > >       hash and rcu patches.
> >
> > There seems to be an issue with the ABI check on those changes.
> > After a quick chat with Dodji, I opened a bug for libabigail.
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=31377
>
> I double checked again and I don't see the struct in question being
> embedded as a field of another struct/union.  So I don't think there should
> be an ABI change here.

That was and is still my understanding too.

The message we get when testing this series is:

                      type size hasn't changed
                      1 data member change:
                        'uint8_t action_data[]' has *some* difference
- please report as a bug

which is why I reached out to Dodji (libabigail maintainer).

Dodji explained me that zero length / flex arrays conversion is
something he has been working on, and there are still some rough
edges.
This message is there so that libabigail community gets more input on
real life cases to handle.


>
> I'm okay with the change being merged but if there is concern I can drop
> this patch from the series.

At least, we can't merge it in the current form.

If libabigail gets a fix quickly, DPDK CI will still need a released version.
So for this patch to be merged now, we need a libabigail suppression rule.
I don't see a way to precisely waive this issue, so my suggestion is
to silence any change on the concerned structure here (which should be
ok, as the pipeline library data struct have been super stable for a
couple of years).
Something like:

$ git diff
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 21b8cd6113..d667157909 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -33,3 +33,5 @@
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ; Temporary exceptions till next major ABI version ;
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+[suppress_type]
+       name = rte_pipeline_table_entry


-- 
David Marchand