Meson buildtype for ci jobs?

Meson buildtype for ci jobs?

[Patrick Robb]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

Hello all,

The lab recently received a request to re-enable Alpine compile jobs, which
have been disabled for almost a year. In dry running the compile job, I
noticed that it was failing. At the same time, David Marchand did an Alpine
compile with Github Actions which was successful. It seems the source of
the different behavior is the meson buildtype being used - the build script
used by GHA sets meson buildtype to debugoptimized, whereas the script used
by the community lab runs with buildtype debug (the meson default). I did
my own Github Actions runs (with both buildtype options) to sanity check:
https://github.com/PatrickRobbIOL/dpdk/actions/runs/4427160204/jobs/7764368640

The reason I'm writing this email is that I'm wondering whether the
buildtype decision made by those who wrote .ci/linux-build.sh for GHA was
intentional and important. I know many of the people who have commits on
that script follow this mailing list. Obviously if it's in some way more
appropriate for CI purposes to run meson setup in this way, I'm happy to
make that change at the lab and in the process that would free up bringing
Alpine compile testing online. But, if not, then I think it's most
appropriate to consider compile on Alpine as broken and avoid bringing
coverage for Alpine online until that issue is resolved.

Any thoughts on the matter are appreciated!

Best,
Patrick

-- 

Patrick Robb

Technical Service Manager

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

www.iol.unh.edu

[-- Attachment #2: Type: text/html, Size: 3687 bytes --]

Re: Meson buildtype for ci jobs?

[David Marchand]

On Wed, Mar 15, 2023 at 4:52 PM Patrick Robb <probb@iol.unh.edu> wrote:
>
> Hello all,
>
> The lab recently received a request to re-enable Alpine compile jobs, which have been disabled for almost a year. In dry running the compile job, I noticed that it was failing. At the same time, David Marchand did an Alpine compile with Github Actions which was successful. It seems the source of the different behavior is the meson buildtype being used - the build script used by GHA sets meson buildtype to debugoptimized, whereas the script used by the community lab runs with buildtype debug (the meson default). I did my own Github Actions runs (with both buildtype options) to sanity check: https://github.com/PatrickRobbIOL/dpdk/actions/runs/4427160204/jobs/7764368640

Are you sure about the default value?

Afaics, meson selects by default a "release" buildtype (and I think I
always saw this value in the past).
I have this with meson 1.0.

$ meson setup qsdlgfh
...
$ meson configure qsdlgfh | grep buildtype
  buildtype                      release
[plain, debug, debugoptimized,   Build type to use

>
> The reason I'm writing this email is that I'm wondering whether the buildtype decision made by those who wrote .ci/linux-build.sh for GHA was intentional and important. I know many of the people who have commits on that script follow this mailing list. Obviously if it's in some way more appropriate for CI purposes to run meson setup in this way, I'm happy to make that change at the lab and in the process that would free up bringing Alpine compile testing online. But, if not, then I think it's most appropriate to consider compile on Alpine as broken and avoid bringing coverage for Alpine online until that issue is resolved.

The reason why we went with debugoptimized was primarly for the ABI
checks, as by default, the debug symbols were missing (which would
match with a "release" default buildtype).
See 777014e56d07 ("devtools: add ABI checks").


-- 
David Marchand

Re: Meson buildtype for ci jobs?

[Patrick Robb]

[-- Attachment #1: Type: text/plain, Size: 4418 bytes --]

>
> On Wed, Mar 15, 2023 at 4:52 PM Patrick Robb <probb@iol.unh.edu> wrote:
>
> Are you sure about the default value?
>
> Afaics, meson selects by default a "release" buildtype (and I think I
> always saw this value in the past).
> I have this with meson 1.0.
>
> $ meson setup qsdlgfh
> ...
> $ meson configure qsdlgfh | grep buildtype
>   buildtype                      release
> [plain, debug, debugoptimized,   Build type to use
>
>
Thanks, you're right - I missed this in the meson.build file. So the
default is release, which is what we run at the lab since we never pass a
custom buildtype option in at meson setup.


> >
> > The reason I'm writing this email is that I'm wondering whether the
> buildtype decision made by those who wrote .ci/linux-build.sh for GHA was
> intentional and important. I know many of the people who have commits on
> that script follow this mailing list. Obviously if it's in some way more
> appropriate for CI purposes to run meson setup in this way, I'm happy to
> make that change at the lab and in the process that would free up bringing
> Alpine compile testing online. But, if not, then I think it's most
> appropriate to consider compile on Alpine as broken and avoid bringing
> coverage for Alpine online until that issue is resolved.
>
> The reason why we went with debugoptimized was primarly for the ABI
> checks, as by default, the debug symbols were missing (which would
> match with a "release" default buildtype).
> See 777014e56d07 ("devtools: add ABI checks").
>

Gotcha. Thanks that makes sense. Well, I guess what I had (unknowingly)
done initially with our Alpine container at the lab was a release build,
but I'll do a release build on GHA to sanity check again anyways, which
will presumably fail.

So, I guess the conclusion is if it doesn't build with the default
buildtype set by meson.build, it's broken and we will not bring Alpine
compile coverage online right now.

Thanks, let me know if you think I'm missing anything here! -Patrick

On Wed, Mar 15, 2023 at 12:08 PM David Marchand <david.marchand@redhat.com>
wrote:

> On Wed, Mar 15, 2023 at 4:52 PM Patrick Robb <probb@iol.unh.edu> wrote:
> >
> > Hello all,
> >
> > The lab recently received a request to re-enable Alpine compile jobs,
> which have been disabled for almost a year. In dry running the compile job,
> I noticed that it was failing. At the same time, David Marchand did an
> Alpine compile with Github Actions which was successful. It seems the
> source of the different behavior is the meson buildtype being used - the
> build script used by GHA sets meson buildtype to debugoptimized, whereas
> the script used by the community lab runs with buildtype debug (the meson
> default). I did my own Github Actions runs (with both buildtype options) to
> sanity check:
> https://github.com/PatrickRobbIOL/dpdk/actions/runs/4427160204/jobs/7764368640
>
> Are you sure about the default value?
>
> Afaics, meson selects by default a "release" buildtype (and I think I
> always saw this value in the past).
> I have this with meson 1.0.
>
> $ meson setup qsdlgfh
> ...
> $ meson configure qsdlgfh | grep buildtype
>   buildtype                      release
> [plain, debug, debugoptimized,   Build type to use
>
> >
> > The reason I'm writing this email is that I'm wondering whether the
> buildtype decision made by those who wrote .ci/linux-build.sh for GHA was
> intentional and important. I know many of the people who have commits on
> that script follow this mailing list. Obviously if it's in some way more
> appropriate for CI purposes to run meson setup in this way, I'm happy to
> make that change at the lab and in the process that would free up bringing
> Alpine compile testing online. But, if not, then I think it's most
> appropriate to consider compile on Alpine as broken and avoid bringing
> coverage for Alpine online until that issue is resolved.
>
> The reason why we went with debugoptimized was primarly for the ABI
> checks, as by default, the debug symbols were missing (which would
> match with a "release" default buildtype).
> See 777014e56d07 ("devtools: add ABI checks").
>
>
> --
> David Marchand
>
>

-- 

Patrick Robb

Technical Service Manager

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

www.iol.unh.edu

[-- Attachment #2: Type: text/html, Size: 7542 bytes --]

RE: Meson buildtype for ci jobs?

[Richardson, Bruce]

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Wednesday, March 15, 2023 4:08 PM
> To: Patrick Robb <probb@iol.unh.edu>
> Cc: ci@dpdk.org; Aaron Conole <aconole@redhat.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Subject: Re: Meson buildtype for ci jobs?
> 
> On Wed, Mar 15, 2023 at 4:52 PM Patrick Robb <probb@iol.unh.edu> wrote:
> >
> > Hello all,
> >
> > The lab recently received a request to re-enable Alpine compile jobs,
> which have been disabled for almost a year. In dry running the compile
> job, I noticed that it was failing. At the same time, David Marchand did
> an Alpine compile with Github Actions which was successful. It seems the
> source of the different behavior is the meson buildtype being used - the
> build script used by GHA sets meson buildtype to debugoptimized, whereas
> the script used by the community lab runs with buildtype debug (the meson
> default). I did my own Github Actions runs (with both buildtype options)
> to sanity check:
> https://github.com/PatrickRobbIOL/dpdk/actions/runs/4427160204/jobs/776436
> 8640
> 
> Are you sure about the default value?
> 
> Afaics, meson selects by default a "release" buildtype (and I think I
> always saw this value in the past).
> I have this with meson 1.0.
> 
> $ meson setup qsdlgfh
> ...
> $ meson configure qsdlgfh | grep buildtype
>   buildtype                      release
> [plain, debug, debugoptimized,   Build type to use
> 
> >
> > The reason I'm writing this email is that I'm wondering whether the
> buildtype decision made by those who wrote .ci/linux-build.sh for GHA was
> intentional and important. I know many of the people who have commits on
> that script follow this mailing list. Obviously if it's in some way more
> appropriate for CI purposes to run meson setup in this way, I'm happy to
> make that change at the lab and in the process that would free up bringing
> Alpine compile testing online. But, if not, then I think it's most
> appropriate to consider compile on Alpine as broken and avoid bringing
> coverage for Alpine online until that issue is resolved.
> 
> The reason why we went with debugoptimized was primarly for the ABI
> checks, as by default, the debug symbols were missing (which would
> match with a "release" default buildtype).
> See 777014e56d07 ("devtools: add ABI checks").
> 

Would passing "-Ddebug=true" be better than changing the default buildtype?
It's possible to have a release build (i.e. O3 optimized) with debug info.

/Bruce

Re: Meson buildtype for ci jobs?

[David Marchand]

On Wed, Mar 15, 2023 at 6:02 PM Richardson, Bruce
<bruce.richardson@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: David Marchand <david.marchand@redhat.com>
> > Sent: Wednesday, March 15, 2023 4:08 PM
> > To: Patrick Robb <probb@iol.unh.edu>
> > Cc: ci@dpdk.org; Aaron Conole <aconole@redhat.com>; Richardson, Bruce
> > <bruce.richardson@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > Subject: Re: Meson buildtype for ci jobs?
> >
> > On Wed, Mar 15, 2023 at 4:52 PM Patrick Robb <probb@iol.unh.edu> wrote:
> > >
> > > Hello all,
> > >
> > > The lab recently received a request to re-enable Alpine compile jobs,
> > which have been disabled for almost a year. In dry running the compile
> > job, I noticed that it was failing. At the same time, David Marchand did
> > an Alpine compile with Github Actions which was successful. It seems the
> > source of the different behavior is the meson buildtype being used - the
> > build script used by GHA sets meson buildtype to debugoptimized, whereas
> > the script used by the community lab runs with buildtype debug (the meson
> > default). I did my own Github Actions runs (with both buildtype options)
> > to sanity check:
> > https://github.com/PatrickRobbIOL/dpdk/actions/runs/4427160204/jobs/776436
> > 8640
> >
> > Are you sure about the default value?
> >
> > Afaics, meson selects by default a "release" buildtype (and I think I
> > always saw this value in the past).
> > I have this with meson 1.0.
> >
> > $ meson setup qsdlgfh
> > ...
> > $ meson configure qsdlgfh | grep buildtype
> >   buildtype                      release
> > [plain, debug, debugoptimized,   Build type to use
> >
> > >
> > > The reason I'm writing this email is that I'm wondering whether the
> > buildtype decision made by those who wrote .ci/linux-build.sh for GHA was
> > intentional and important. I know many of the people who have commits on
> > that script follow this mailing list. Obviously if it's in some way more
> > appropriate for CI purposes to run meson setup in this way, I'm happy to
> > make that change at the lab and in the process that would free up bringing
> > Alpine compile testing online. But, if not, then I think it's most
> > appropriate to consider compile on Alpine as broken and avoid bringing
> > coverage for Alpine online until that issue is resolved.
> >
> > The reason why we went with debugoptimized was primarly for the ABI
> > checks, as by default, the debug symbols were missing (which would
> > match with a "release" default buildtype).
> > See 777014e56d07 ("devtools: add ABI checks").
> >
>
> Would passing "-Ddebug=true" be better than changing the default buildtype?
> It's possible to have a release build (i.e. O3 optimized) with debug info.

I would expect it to work, though I never tried it as I understood
what optimization, debug and buildtype relations were recently, only
:-).


-- 
David marchand

RE: Meson buildtype for ci jobs?

[Richardson, Bruce]

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Wednesday, March 15, 2023 5:10 PM
> To: Richardson, Bruce <bruce.richardson@intel.com>
> Cc: Patrick Robb <probb@iol.unh.edu>; ci@dpdk.org; Aaron Conole
> <aconole@redhat.com>; Thomas Monjalon <thomas@monjalon.net>
> Subject: Re: Meson buildtype for ci jobs?
> 
> On Wed, Mar 15, 2023 at 6:02 PM Richardson, Bruce
> <bruce.richardson@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: David Marchand <david.marchand@redhat.com>
> > > Sent: Wednesday, March 15, 2023 4:08 PM
> > > To: Patrick Robb <probb@iol.unh.edu>
> > > Cc: ci@dpdk.org; Aaron Conole <aconole@redhat.com>; Richardson, Bruce
> > > <bruce.richardson@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > > Subject: Re: Meson buildtype for ci jobs?
> > >
> > > On Wed, Mar 15, 2023 at 4:52 PM Patrick Robb <probb@iol.unh.edu>
> wrote:
> > > >
> > > > Hello all,
> > > >
> > > > The lab recently received a request to re-enable Alpine compile
> jobs,
> > > which have been disabled for almost a year. In dry running the compile
> > > job, I noticed that it was failing. At the same time, David Marchand
> did
> > > an Alpine compile with Github Actions which was successful. It seems
> the
> > > source of the different behavior is the meson buildtype being used -
> the
> > > build script used by GHA sets meson buildtype to debugoptimized,
> whereas
> > > the script used by the community lab runs with buildtype debug (the
> meson
> > > default). I did my own Github Actions runs (with both buildtype
> options)
> > > to sanity check:
> > >
> https://github.com/PatrickRobbIOL/dpdk/actions/runs/4427160204/jobs/776436
> > > 8640
> > >
> > > Are you sure about the default value?
> > >
> > > Afaics, meson selects by default a "release" buildtype (and I think I
> > > always saw this value in the past).
> > > I have this with meson 1.0.
> > >
> > > $ meson setup qsdlgfh
> > > ...
> > > $ meson configure qsdlgfh | grep buildtype
> > >   buildtype                      release
> > > [plain, debug, debugoptimized,   Build type to use
> > >
> > > >
> > > > The reason I'm writing this email is that I'm wondering whether the
> > > buildtype decision made by those who wrote .ci/linux-build.sh for GHA
> was
> > > intentional and important. I know many of the people who have commits
> on
> > > that script follow this mailing list. Obviously if it's in some way
> more
> > > appropriate for CI purposes to run meson setup in this way, I'm happy
> to
> > > make that change at the lab and in the process that would free up
> bringing
> > > Alpine compile testing online. But, if not, then I think it's most
> > > appropriate to consider compile on Alpine as broken and avoid bringing
> > > coverage for Alpine online until that issue is resolved.
> > >
> > > The reason why we went with debugoptimized was primarly for the ABI
> > > checks, as by default, the debug symbols were missing (which would
> > > match with a "release" default buildtype).
> > > See 777014e56d07 ("devtools: add ABI checks").
> > >
> >
> > Would passing "-Ddebug=true" be better than changing the default
> buildtype?
> > It's possible to have a release build (i.e. O3 optimized) with debug
> info.
> 
> I would expect it to work, though I never tried it as I understood
> what optimization, debug and buildtype relations were recently, only
> :-).
> 

For a given value of "recent". 😊

Re: Meson buildtype for ci jobs?

[Patrick Robb]

[-- Attachment #1: Type: text/plain, Size: 3691 bytes --]

>
> Would passing "-Ddebug=true" be better than changing the default buildtype?
> It's possible to have a release build (i.e. O3 optimized) with debug info.
>

Strangely, even with -Ddebug true if I'm running buildtype "release" it
returns the same warnings. I'm inferring from your comment that release
optimization == debugoptimized optimization and debug behavior from
-Ddebug=true == debug behavior from debugoptimized, so release buildtype +
debug "should" have the same behavior as just setting buildtype
debugoptimized, and yet...

I'll have to look into this a little more. Hopefully by the end I'll be
like David and understand the relations between these flags better, hah.

On Wed, Mar 15, 2023 at 1:02 PM Richardson, Bruce <
bruce.richardson@intel.com> wrote:

>
>
> > -----Original Message-----
> > From: David Marchand <david.marchand@redhat.com>
> > Sent: Wednesday, March 15, 2023 4:08 PM
> > To: Patrick Robb <probb@iol.unh.edu>
> > Cc: ci@dpdk.org; Aaron Conole <aconole@redhat.com>; Richardson, Bruce
> > <bruce.richardson@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > Subject: Re: Meson buildtype for ci jobs?
> >
> > On Wed, Mar 15, 2023 at 4:52 PM Patrick Robb <probb@iol.unh.edu> wrote:
> > >
> > > Hello all,
> > >
> > > The lab recently received a request to re-enable Alpine compile jobs,
> > which have been disabled for almost a year. In dry running the compile
> > job, I noticed that it was failing. At the same time, David Marchand did
> > an Alpine compile with Github Actions which was successful. It seems the
> > source of the different behavior is the meson buildtype being used - the
> > build script used by GHA sets meson buildtype to debugoptimized, whereas
> > the script used by the community lab runs with buildtype debug (the meson
> > default). I did my own Github Actions runs (with both buildtype options)
> > to sanity check:
> >
> https://github.com/PatrickRobbIOL/dpdk/actions/runs/4427160204/jobs/776436
> > 8640
> >
> > Are you sure about the default value?
> >
> > Afaics, meson selects by default a "release" buildtype (and I think I
> > always saw this value in the past).
> > I have this with meson 1.0.
> >
> > $ meson setup qsdlgfh
> > ...
> > $ meson configure qsdlgfh | grep buildtype
> >   buildtype                      release
> > [plain, debug, debugoptimized,   Build type to use
> >
> > >
> > > The reason I'm writing this email is that I'm wondering whether the
> > buildtype decision made by those who wrote .ci/linux-build.sh for GHA was
> > intentional and important. I know many of the people who have commits on
> > that script follow this mailing list. Obviously if it's in some way more
> > appropriate for CI purposes to run meson setup in this way, I'm happy to
> > make that change at the lab and in the process that would free up
> bringing
> > Alpine compile testing online. But, if not, then I think it's most
> > appropriate to consider compile on Alpine as broken and avoid bringing
> > coverage for Alpine online until that issue is resolved.
> >
> > The reason why we went with debugoptimized was primarly for the ABI
> > checks, as by default, the debug symbols were missing (which would
> > match with a "release" default buildtype).
> > See 777014e56d07 ("devtools: add ABI checks").
> >
>
> Would passing "-Ddebug=true" be better than changing the default buildtype?
> It's possible to have a release build (i.e. O3 optimized) with debug info.
>
> /Bruce
>


-- 

Patrick Robb

Technical Service Manager

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

www.iol.unh.edu

[-- Attachment #2: Type: text/html, Size: 7020 bytes --]

Re: Meson buildtype for ci jobs?

[David Marchand]

Adding dev@ mailing list and ring maintainers,

On Wed, Mar 15, 2023 at 8:13 PM Patrick Robb <probb@iol.unh.edu> wrote:
>>
>> Would passing "-Ddebug=true" be better than changing the default buildtype?
>> It's possible to have a release build (i.e. O3 optimized) with debug info.
>
>
> Strangely, even with -Ddebug true if I'm running buildtype "release" it returns the same warnings. I'm inferring from your comment that release optimization == debugoptimized optimization and debug behavior from -Ddebug=true == debug behavior from debugoptimized, so release buildtype + debug "should" have the same behavior as just setting buildtype debugoptimized, and yet...
>
> I'll have to look into this a little more. Hopefully by the end I'll be like David and understand the relations between these flags better, hah.

As for how buildtype, optimizations and debug params are concerned,
the summary is here:
https://mesonbuild.com/Builtin-options.html#details-for-buildtype


In my tests this morning with a Alpine container, I noticed that
setting -Dplatform to native makes the issue disappear...
So an additional factor is building with platform=generic.

~/dpdk # meson configure build | awk '{if ($1 ~
/^(buildtype|platform|debug|optimization)$/) { print $0; }}'
  buildtype              debug               [plain, debug,
debugoptimized, release, minsize, custom]      Build type to use
  debug                  true                [true, false]
                                    Debug
  optimization           0                   [0, g, 1, 2, 3, s]
                                    Optimization level
  platform               generic
                                    Platform to build, either
"native", "generic" or a SoC. Please refer to the Linux build guide
for more information.

...

In file included from ../lib/ring/rte_ring_elem.h:24,
                 from ../lib/ring/rte_ring.h:43,
                 from ../lib/mempool/rte_mempool.h:47,
                 from ../lib/mbuf/rte_mbuf.h:38,
                 from ../lib/net/rte_ether.h:22,
                 from ../lib/ethdev/rte_eth_ctrl.h:10,
                 from ../lib/ethdev/rte_ethdev.h:1421,
                 from ../app/test/test_event_timer_adapter.c:14:
In function '__rte_ring_enqueue_elems_128',
    inlined from '__rte_ring_enqueue_elems' at
../lib/ring/rte_ring_elem_pvt.h:132:3,
    inlined from '__rte_ring_do_enqueue_elem' at
../lib/ring/rte_ring_elem_pvt.h:328:2,
    inlined from 'rte_ring_mp_enqueue_bulk_elem' at
../lib/ring/rte_ring_elem.h:134:9,
    inlined from 'rte_ring_enqueue_bulk_elem' at
../lib/ring/rte_ring_elem.h:199:10,
    inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
    inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
    inlined from '_cancel_producer' at
../app/test/test_event_timer_adapter.c:834:10:
../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
bytes from a region of size 8 [-Werror=stringop-overread]
  100 |                         memcpy((void *)(ring + idx),
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  101 |                                 (const void *)(obj + i), 32);
      |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
../app/test/test_event_timer_adapter.c:805:1: note: source object
'obj' of size 8
  805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
      | ^~~~~~~~~~~~~~~~
In function '__rte_ring_enqueue_elems_128',
    inlined from '__rte_ring_enqueue_elems' at
../lib/ring/rte_ring_elem_pvt.h:132:3,
    inlined from '__rte_ring_do_enqueue_elem' at
../lib/ring/rte_ring_elem_pvt.h:328:2,
    inlined from 'rte_ring_sp_enqueue_bulk_elem' at
../lib/ring/rte_ring_elem.h:163:9,
    inlined from 'rte_ring_enqueue_bulk_elem' at
../lib/ring/rte_ring_elem.h:202:10,
    inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
    inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
    inlined from '_cancel_producer' at
../app/test/test_event_timer_adapter.c:834:10:
../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
bytes from a region of size 8 [-Werror=stringop-overread]
  100 |                         memcpy((void *)(ring + idx),
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  101 |                                 (const void *)(obj + i), 32);
      |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
../app/test/test_event_timer_adapter.c:805:1: note: source object
'obj' of size 8
  805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
      | ^~~~~~~~~~~~~~~~
In function '__rte_ring_enqueue_elems_128',
    inlined from '__rte_ring_enqueue_elems' at
../lib/ring/rte_ring_elem_pvt.h:132:3,
    inlined from '__rte_ring_do_rts_enqueue_elem' at
../lib/ring/rte_ring_rts_elem_pvt.h:211:3,
    inlined from 'rte_ring_mp_rts_enqueue_bulk_elem' at
../lib/ring/rte_ring_rts.h:83:9,
    inlined from 'rte_ring_enqueue_bulk_elem' at
../lib/ring/rte_ring_elem.h:205:10,
    inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
    inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
    inlined from '_cancel_producer' at
../app/test/test_event_timer_adapter.c:834:10:
../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
bytes from a region of size 8 [-Werror=stringop-overread]
  100 |                         memcpy((void *)(ring + idx),
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  101 |                                 (const void *)(obj + i), 32);
      |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
../app/test/test_event_timer_adapter.c:805:1: note: source object
'obj' of size 8
  805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
      | ^~~~~~~~~~~~~~~~
In function '__rte_ring_enqueue_elems_128',
    inlined from '__rte_ring_enqueue_elems' at
../lib/ring/rte_ring_elem_pvt.h:132:3,
    inlined from '__rte_ring_do_hts_enqueue_elem' at
../lib/ring/rte_ring_hts_elem_pvt.h:196:3,
    inlined from 'rte_ring_mp_hts_enqueue_bulk_elem' at
../lib/ring/rte_ring_hts.h:56:9,
    inlined from 'rte_ring_enqueue_bulk_elem' at
../lib/ring/rte_ring_elem.h:208:10,
    inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
    inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
    inlined from '_cancel_producer' at
../app/test/test_event_timer_adapter.c:834:10:
../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
bytes from a region of size 8 [-Werror=stringop-overread]
  100 |                         memcpy((void *)(ring + idx),
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  101 |                                 (const void *)(obj + i), 32);
      |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
../app/test/test_event_timer_adapter.c:805:1: note: source object
'obj' of size 8
  805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
      | ^~~~~~~~~~~~~~~~
In function '__rte_ring_dequeue_elems_128',
    inlined from '__rte_ring_dequeue_elems' at
../lib/ring/rte_ring_elem_pvt.h:262:3,
    inlined from '__rte_ring_do_dequeue_elem' at
../lib/ring/rte_ring_elem_pvt.h:375:2,
    inlined from 'rte_ring_mc_dequeue_bulk_elem' at
../lib/ring/rte_ring_elem.h:320:9,
    inlined from 'rte_ring_dequeue_bulk_elem' at
../lib/ring/rte_ring_elem.h:381:10,
    inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
    inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
    inlined from '_cancel_thread' at
../app/test/test_event_timer_adapter.c:917:7:
../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
bytes into a region of size 8 overflows the destination
[-Werror=stringop-overflow=]
  234 |                         memcpy((void *)(obj + i), (void
*)(ring + idx), 32);
      |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
../app/test/test_event_timer_adapter.c:913:33: note: destination
object 'ev_tim' of size 8
  913 |         struct rte_event_timer *ev_tim = NULL;
      |                                 ^~~~~~
In function '__rte_ring_dequeue_elems_128',
    inlined from '__rte_ring_dequeue_elems' at
../lib/ring/rte_ring_elem_pvt.h:262:3,
    inlined from '__rte_ring_do_dequeue_elem' at
../lib/ring/rte_ring_elem_pvt.h:375:2,
    inlined from 'rte_ring_sc_dequeue_bulk_elem' at
../lib/ring/rte_ring_elem.h:348:9,
    inlined from 'rte_ring_dequeue_bulk_elem' at
../lib/ring/rte_ring_elem.h:384:10,
    inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
    inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
    inlined from '_cancel_thread' at
../app/test/test_event_timer_adapter.c:917:7:
../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
bytes into a region of size 8 overflows the destination
[-Werror=stringop-overflow=]
  234 |                         memcpy((void *)(obj + i), (void
*)(ring + idx), 32);
      |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
../app/test/test_event_timer_adapter.c:913:33: note: destination
object 'ev_tim' of size 8
  913 |         struct rte_event_timer *ev_tim = NULL;
      |                                 ^~~~~~
In function '__rte_ring_dequeue_elems_128',
    inlined from '__rte_ring_dequeue_elems' at
../lib/ring/rte_ring_elem_pvt.h:262:3,
    inlined from '__rte_ring_do_rts_dequeue_elem' at
../lib/ring/rte_ring_rts_elem_pvt.h:252:3,
    inlined from 'rte_ring_mc_rts_dequeue_bulk_elem' at
../lib/ring/rte_ring_rts.h:110:9,
    inlined from 'rte_ring_dequeue_bulk_elem' at
../lib/ring/rte_ring_elem.h:387:10,
    inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
    inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
    inlined from '_cancel_thread' at
../app/test/test_event_timer_adapter.c:917:7:
../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
bytes into a region of size 8 overflows the destination
[-Werror=stringop-overflow=]
  234 |                         memcpy((void *)(obj + i), (void
*)(ring + idx), 32);
      |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
../app/test/test_event_timer_adapter.c:913:33: note: destination
object 'ev_tim' of size 8
  913 |         struct rte_event_timer *ev_tim = NULL;
      |                                 ^~~~~~
In function '__rte_ring_dequeue_elems_128',
    inlined from '__rte_ring_dequeue_elems' at
../lib/ring/rte_ring_elem_pvt.h:262:3,
    inlined from '__rte_ring_do_hts_dequeue_elem' at
../lib/ring/rte_ring_hts_elem_pvt.h:237:3,
    inlined from 'rte_ring_mc_hts_dequeue_bulk_elem' at
../lib/ring/rte_ring_hts.h:83:9,
    inlined from 'rte_ring_dequeue_bulk_elem' at
../lib/ring/rte_ring_elem.h:390:10,
    inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
    inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
    inlined from '_cancel_thread' at
../app/test/test_event_timer_adapter.c:917:7:
../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
bytes into a region of size 8 overflows the destination
[-Werror=stringop-overflow=]
  234 |                         memcpy((void *)(obj + i), (void
*)(ring + idx), 32);
      |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
../app/test/test_event_timer_adapter.c:913:33: note: destination
object 'ev_tim' of size 8
  913 |         struct rte_event_timer *ev_tim = NULL;
      |                                 ^~~~~~
cc1: all warnings being treated as errors
ninja: subcommands failed


This is gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924.

The compiler seems unhappy about the rte_int128_t type.
The below hunk seems to (confuse?) help the compiler.

diff --git a/lib/ring/rte_ring_elem_pvt.h b/lib/ring/rte_ring_elem_pvt.h
index 83788c56e6..ece937f8e1 100644
--- a/lib/ring/rte_ring_elem_pvt.h
+++ b/lib/ring/rte_ring_elem_pvt.h
@@ -98,7 +98,7 @@ __rte_ring_enqueue_elems_128(struct rte_ring *r,
uint32_t prod_head,
     if (likely(idx + n <= size)) {
         for (i = 0; i < (n & ~0x1); i += 2, idx += 2)
             memcpy((void *)(ring + idx),
-                (const void *)(obj + i), 32);
+                (const void *)((uintptr_t)obj + i), 32);
         switch (n & 0x1) {
         case 1:
             memcpy((void *)(ring + idx),
@@ -231,7 +231,7 @@ __rte_ring_dequeue_elems_128(struct rte_ring *r,
uint32_t prod_head,
     rte_int128_t *obj = (rte_int128_t *)obj_table;
     if (likely(idx + n <= size)) {
         for (i = 0; i < (n & ~0x1); i += 2, idx += 2)
-            memcpy((void *)(obj + i), (void *)(ring + idx), 32);
+            memcpy((void *)((uintptr_t)obj + i), (void *)(ring + idx), 32);
         switch (n & 0x1) {
         case 1:
             memcpy((void *)(obj + i), (void *)(ring + idx), 16);


RTE_PTR_ADD has the same effect.


-- 
David Marchand

Re: Meson buildtype for ci jobs?

[David Marchand]

On Thu, Mar 16, 2023 at 9:49 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> Adding dev@ mailing list and ring maintainers,
>
> On Wed, Mar 15, 2023 at 8:13 PM Patrick Robb <probb@iol.unh.edu> wrote:
> >>
> >> Would passing "-Ddebug=true" be better than changing the default buildtype?
> >> It's possible to have a release build (i.e. O3 optimized) with debug info.
> >
> >
> > Strangely, even with -Ddebug true if I'm running buildtype "release" it returns the same warnings. I'm inferring from your comment that release optimization == debugoptimized optimization and debug behavior from -Ddebug=true == debug behavior from debugoptimized, so release buildtype + debug "should" have the same behavior as just setting buildtype debugoptimized, and yet...
> >
> > I'll have to look into this a little more. Hopefully by the end I'll be like David and understand the relations between these flags better, hah.
>
> As for how buildtype, optimizations and debug params are concerned,
> the summary is here:
> https://mesonbuild.com/Builtin-options.html#details-for-buildtype
>
>
> In my tests this morning with a Alpine container, I noticed that
> setting -Dplatform to native makes the issue disappear...
> So an additional factor is building with platform=generic.
>
> ~/dpdk # meson configure build | awk '{if ($1 ~
> /^(buildtype|platform|debug|optimization)$/) { print $0; }}'
>   buildtype              debug               [plain, debug,
> debugoptimized, release, minsize, custom]      Build type to use
>   debug                  true                [true, false]
>                                     Debug
>   optimization           0                   [0, g, 1, 2, 3, s]
>                                     Optimization level
>   platform               generic
>                                     Platform to build, either
> "native", "generic" or a SoC. Please refer to the Linux build guide
> for more information.
>
> ...
>
> In file included from ../lib/ring/rte_ring_elem.h:24,
>                  from ../lib/ring/rte_ring.h:43,
>                  from ../lib/mempool/rte_mempool.h:47,
>                  from ../lib/mbuf/rte_mbuf.h:38,
>                  from ../lib/net/rte_ether.h:22,
>                  from ../lib/ethdev/rte_eth_ctrl.h:10,
>                  from ../lib/ethdev/rte_ethdev.h:1421,
>                  from ../app/test/test_event_timer_adapter.c:14:
> In function '__rte_ring_enqueue_elems_128',
>     inlined from '__rte_ring_enqueue_elems' at
> ../lib/ring/rte_ring_elem_pvt.h:132:3,
>     inlined from '__rte_ring_do_enqueue_elem' at
> ../lib/ring/rte_ring_elem_pvt.h:328:2,
>     inlined from 'rte_ring_mp_enqueue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:134:9,
>     inlined from 'rte_ring_enqueue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:199:10,
>     inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
>     inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
>     inlined from '_cancel_producer' at
> ../app/test/test_event_timer_adapter.c:834:10:
> ../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
> bytes from a region of size 8 [-Werror=stringop-overread]
>   100 |                         memcpy((void *)(ring + idx),
>       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   101 |                                 (const void *)(obj + i), 32);
>       |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
> ../app/test/test_event_timer_adapter.c:805:1: note: source object
> 'obj' of size 8
>   805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
>       | ^~~~~~~~~~~~~~~~
> In function '__rte_ring_enqueue_elems_128',
>     inlined from '__rte_ring_enqueue_elems' at
> ../lib/ring/rte_ring_elem_pvt.h:132:3,
>     inlined from '__rte_ring_do_enqueue_elem' at
> ../lib/ring/rte_ring_elem_pvt.h:328:2,
>     inlined from 'rte_ring_sp_enqueue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:163:9,
>     inlined from 'rte_ring_enqueue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:202:10,
>     inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
>     inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
>     inlined from '_cancel_producer' at
> ../app/test/test_event_timer_adapter.c:834:10:
> ../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
> bytes from a region of size 8 [-Werror=stringop-overread]
>   100 |                         memcpy((void *)(ring + idx),
>       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   101 |                                 (const void *)(obj + i), 32);
>       |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
> ../app/test/test_event_timer_adapter.c:805:1: note: source object
> 'obj' of size 8
>   805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
>       | ^~~~~~~~~~~~~~~~
> In function '__rte_ring_enqueue_elems_128',
>     inlined from '__rte_ring_enqueue_elems' at
> ../lib/ring/rte_ring_elem_pvt.h:132:3,
>     inlined from '__rte_ring_do_rts_enqueue_elem' at
> ../lib/ring/rte_ring_rts_elem_pvt.h:211:3,
>     inlined from 'rte_ring_mp_rts_enqueue_bulk_elem' at
> ../lib/ring/rte_ring_rts.h:83:9,
>     inlined from 'rte_ring_enqueue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:205:10,
>     inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
>     inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
>     inlined from '_cancel_producer' at
> ../app/test/test_event_timer_adapter.c:834:10:
> ../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
> bytes from a region of size 8 [-Werror=stringop-overread]
>   100 |                         memcpy((void *)(ring + idx),
>       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   101 |                                 (const void *)(obj + i), 32);
>       |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
> ../app/test/test_event_timer_adapter.c:805:1: note: source object
> 'obj' of size 8
>   805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
>       | ^~~~~~~~~~~~~~~~
> In function '__rte_ring_enqueue_elems_128',
>     inlined from '__rte_ring_enqueue_elems' at
> ../lib/ring/rte_ring_elem_pvt.h:132:3,
>     inlined from '__rte_ring_do_hts_enqueue_elem' at
> ../lib/ring/rte_ring_hts_elem_pvt.h:196:3,
>     inlined from 'rte_ring_mp_hts_enqueue_bulk_elem' at
> ../lib/ring/rte_ring_hts.h:56:9,
>     inlined from 'rte_ring_enqueue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:208:10,
>     inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
>     inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
>     inlined from '_cancel_producer' at
> ../app/test/test_event_timer_adapter.c:834:10:
> ../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
> bytes from a region of size 8 [-Werror=stringop-overread]
>   100 |                         memcpy((void *)(ring + idx),
>       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   101 |                                 (const void *)(obj + i), 32);
>       |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
> ../app/test/test_event_timer_adapter.c:805:1: note: source object
> 'obj' of size 8
>   805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
>       | ^~~~~~~~~~~~~~~~
> In function '__rte_ring_dequeue_elems_128',
>     inlined from '__rte_ring_dequeue_elems' at
> ../lib/ring/rte_ring_elem_pvt.h:262:3,
>     inlined from '__rte_ring_do_dequeue_elem' at
> ../lib/ring/rte_ring_elem_pvt.h:375:2,
>     inlined from 'rte_ring_mc_dequeue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:320:9,
>     inlined from 'rte_ring_dequeue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:381:10,
>     inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
>     inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
>     inlined from '_cancel_thread' at
> ../app/test/test_event_timer_adapter.c:917:7:
> ../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
> bytes into a region of size 8 overflows the destination
> [-Werror=stringop-overflow=]
>   234 |                         memcpy((void *)(obj + i), (void
> *)(ring + idx), 32);
>       |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
> ../app/test/test_event_timer_adapter.c:913:33: note: destination
> object 'ev_tim' of size 8
>   913 |         struct rte_event_timer *ev_tim = NULL;
>       |                                 ^~~~~~
> In function '__rte_ring_dequeue_elems_128',
>     inlined from '__rte_ring_dequeue_elems' at
> ../lib/ring/rte_ring_elem_pvt.h:262:3,
>     inlined from '__rte_ring_do_dequeue_elem' at
> ../lib/ring/rte_ring_elem_pvt.h:375:2,
>     inlined from 'rte_ring_sc_dequeue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:348:9,
>     inlined from 'rte_ring_dequeue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:384:10,
>     inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
>     inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
>     inlined from '_cancel_thread' at
> ../app/test/test_event_timer_adapter.c:917:7:
> ../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
> bytes into a region of size 8 overflows the destination
> [-Werror=stringop-overflow=]
>   234 |                         memcpy((void *)(obj + i), (void
> *)(ring + idx), 32);
>       |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
> ../app/test/test_event_timer_adapter.c:913:33: note: destination
> object 'ev_tim' of size 8
>   913 |         struct rte_event_timer *ev_tim = NULL;
>       |                                 ^~~~~~
> In function '__rte_ring_dequeue_elems_128',
>     inlined from '__rte_ring_dequeue_elems' at
> ../lib/ring/rte_ring_elem_pvt.h:262:3,
>     inlined from '__rte_ring_do_rts_dequeue_elem' at
> ../lib/ring/rte_ring_rts_elem_pvt.h:252:3,
>     inlined from 'rte_ring_mc_rts_dequeue_bulk_elem' at
> ../lib/ring/rte_ring_rts.h:110:9,
>     inlined from 'rte_ring_dequeue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:387:10,
>     inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
>     inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
>     inlined from '_cancel_thread' at
> ../app/test/test_event_timer_adapter.c:917:7:
> ../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
> bytes into a region of size 8 overflows the destination
> [-Werror=stringop-overflow=]
>   234 |                         memcpy((void *)(obj + i), (void
> *)(ring + idx), 32);
>       |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
> ../app/test/test_event_timer_adapter.c:913:33: note: destination
> object 'ev_tim' of size 8
>   913 |         struct rte_event_timer *ev_tim = NULL;
>       |                                 ^~~~~~
> In function '__rte_ring_dequeue_elems_128',
>     inlined from '__rte_ring_dequeue_elems' at
> ../lib/ring/rte_ring_elem_pvt.h:262:3,
>     inlined from '__rte_ring_do_hts_dequeue_elem' at
> ../lib/ring/rte_ring_hts_elem_pvt.h:237:3,
>     inlined from 'rte_ring_mc_hts_dequeue_bulk_elem' at
> ../lib/ring/rte_ring_hts.h:83:9,
>     inlined from 'rte_ring_dequeue_bulk_elem' at
> ../lib/ring/rte_ring_elem.h:390:10,
>     inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
>     inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
>     inlined from '_cancel_thread' at
> ../app/test/test_event_timer_adapter.c:917:7:
> ../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
> bytes into a region of size 8 overflows the destination
> [-Werror=stringop-overflow=]
>   234 |                         memcpy((void *)(obj + i), (void
> *)(ring + idx), 32);
>       |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
> ../app/test/test_event_timer_adapter.c:913:33: note: destination
> object 'ev_tim' of size 8
>   913 |         struct rte_event_timer *ev_tim = NULL;
>       |                                 ^~~~~~
> cc1: all warnings being treated as errors
> ninja: subcommands failed
>
>
> This is gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924.
>
> The compiler seems unhappy about the rte_int128_t type.
> The below hunk seems to (confuse?) help the compiler.
>
> diff --git a/lib/ring/rte_ring_elem_pvt.h b/lib/ring/rte_ring_elem_pvt.h
> index 83788c56e6..ece937f8e1 100644
> --- a/lib/ring/rte_ring_elem_pvt.h
> +++ b/lib/ring/rte_ring_elem_pvt.h
> @@ -98,7 +98,7 @@ __rte_ring_enqueue_elems_128(struct rte_ring *r,
> uint32_t prod_head,
>      if (likely(idx + n <= size)) {
>          for (i = 0; i < (n & ~0x1); i += 2, idx += 2)
>              memcpy((void *)(ring + idx),
> -                (const void *)(obj + i), 32);
> +                (const void *)((uintptr_t)obj + i), 32);
>          switch (n & 0x1) {
>          case 1:
>              memcpy((void *)(ring + idx),
> @@ -231,7 +231,7 @@ __rte_ring_dequeue_elems_128(struct rte_ring *r,
> uint32_t prod_head,
>      rte_int128_t *obj = (rte_int128_t *)obj_table;
>      if (likely(idx + n <= size)) {
>          for (i = 0; i < (n & ~0x1); i += 2, idx += 2)
> -            memcpy((void *)(obj + i), (void *)(ring + idx), 32);
> +            memcpy((void *)((uintptr_t)obj + i), (void *)(ring + idx), 32);
>          switch (n & 0x1) {
>          case 1:
>              memcpy((void *)(obj + i), (void *)(ring + idx), 16);
>
>
> RTE_PTR_ADD has the same effect.
>

This seems what Kevin had worked around for 21.11 release:
https://inbox.dpdk.org/stable/20221220123754.239802-1-ktraynor@redhat.com/

I would tend to do the same and disable this warning for rc3 at least,
and have stable branches and the main repository aligned.
We can have a better fix later.

Opinions?


-- 
David Marchand

Re: Meson buildtype for ci jobs?

[Bruce Richardson]

On Thu, Mar 16, 2023 at 10:08:47AM +0100, David Marchand wrote:
> On Thu, Mar 16, 2023 at 9:49 AM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > Adding dev@ mailing list and ring maintainers,
> >
> > On Wed, Mar 15, 2023 at 8:13 PM Patrick Robb <probb@iol.unh.edu> wrote:
> > >>
> > >> Would passing "-Ddebug=true" be better than changing the default buildtype?
> > >> It's possible to have a release build (i.e. O3 optimized) with debug info.
> > >
> > >
> > > Strangely, even with -Ddebug true if I'm running buildtype "release" it returns the same warnings. I'm inferring from your comment that release optimization == debugoptimized optimization and debug behavior from -Ddebug=true == debug behavior from debugoptimized, so release buildtype + debug "should" have the same behavior as just setting buildtype debugoptimized, and yet...
> > >
> > > I'll have to look into this a little more. Hopefully by the end I'll be like David and understand the relations between these flags better, hah.
> >
> > As for how buildtype, optimizations and debug params are concerned,
> > the summary is here:
> > https://mesonbuild.com/Builtin-options.html#details-for-buildtype
> >
> >
> > In my tests this morning with a Alpine container, I noticed that
> > setting -Dplatform to native makes the issue disappear...
> > So an additional factor is building with platform=generic.
> >
> > ~/dpdk # meson configure build | awk '{if ($1 ~
> > /^(buildtype|platform|debug|optimization)$/) { print $0; }}'
> >   buildtype              debug               [plain, debug,
> > debugoptimized, release, minsize, custom]      Build type to use
> >   debug                  true                [true, false]
> >                                     Debug
> >   optimization           0                   [0, g, 1, 2, 3, s]
> >                                     Optimization level
> >   platform               generic
> >                                     Platform to build, either
> > "native", "generic" or a SoC. Please refer to the Linux build guide
> > for more information.
> >
> > ...
> >
> > In file included from ../lib/ring/rte_ring_elem.h:24,
> >                  from ../lib/ring/rte_ring.h:43,
> >                  from ../lib/mempool/rte_mempool.h:47,
> >                  from ../lib/mbuf/rte_mbuf.h:38,
> >                  from ../lib/net/rte_ether.h:22,
> >                  from ../lib/ethdev/rte_eth_ctrl.h:10,
> >                  from ../lib/ethdev/rte_ethdev.h:1421,
> >                  from ../app/test/test_event_timer_adapter.c:14:
> > In function '__rte_ring_enqueue_elems_128',
> >     inlined from '__rte_ring_enqueue_elems' at
> > ../lib/ring/rte_ring_elem_pvt.h:132:3,
> >     inlined from '__rte_ring_do_enqueue_elem' at
> > ../lib/ring/rte_ring_elem_pvt.h:328:2,
> >     inlined from 'rte_ring_mp_enqueue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:134:9,
> >     inlined from 'rte_ring_enqueue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:199:10,
> >     inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
> >     inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
> >     inlined from '_cancel_producer' at
> > ../app/test/test_event_timer_adapter.c:834:10:
> > ../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
> > bytes from a region of size 8 [-Werror=stringop-overread]
> >   100 |                         memcpy((void *)(ring + idx),
> >       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   101 |                                 (const void *)(obj + i), 32);
> >       |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
> > ../app/test/test_event_timer_adapter.c:805:1: note: source object
> > 'obj' of size 8
> >   805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
> >       | ^~~~~~~~~~~~~~~~
> > In function '__rte_ring_enqueue_elems_128',
> >     inlined from '__rte_ring_enqueue_elems' at
> > ../lib/ring/rte_ring_elem_pvt.h:132:3,
> >     inlined from '__rte_ring_do_enqueue_elem' at
> > ../lib/ring/rte_ring_elem_pvt.h:328:2,
> >     inlined from 'rte_ring_sp_enqueue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:163:9,
> >     inlined from 'rte_ring_enqueue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:202:10,
> >     inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
> >     inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
> >     inlined from '_cancel_producer' at
> > ../app/test/test_event_timer_adapter.c:834:10:
> > ../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
> > bytes from a region of size 8 [-Werror=stringop-overread]
> >   100 |                         memcpy((void *)(ring + idx),
> >       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   101 |                                 (const void *)(obj + i), 32);
> >       |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
> > ../app/test/test_event_timer_adapter.c:805:1: note: source object
> > 'obj' of size 8
> >   805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
> >       | ^~~~~~~~~~~~~~~~
> > In function '__rte_ring_enqueue_elems_128',
> >     inlined from '__rte_ring_enqueue_elems' at
> > ../lib/ring/rte_ring_elem_pvt.h:132:3,
> >     inlined from '__rte_ring_do_rts_enqueue_elem' at
> > ../lib/ring/rte_ring_rts_elem_pvt.h:211:3,
> >     inlined from 'rte_ring_mp_rts_enqueue_bulk_elem' at
> > ../lib/ring/rte_ring_rts.h:83:9,
> >     inlined from 'rte_ring_enqueue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:205:10,
> >     inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
> >     inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
> >     inlined from '_cancel_producer' at
> > ../app/test/test_event_timer_adapter.c:834:10:
> > ../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
> > bytes from a region of size 8 [-Werror=stringop-overread]
> >   100 |                         memcpy((void *)(ring + idx),
> >       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   101 |                                 (const void *)(obj + i), 32);
> >       |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
> > ../app/test/test_event_timer_adapter.c:805:1: note: source object
> > 'obj' of size 8
> >   805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
> >       | ^~~~~~~~~~~~~~~~
> > In function '__rte_ring_enqueue_elems_128',
> >     inlined from '__rte_ring_enqueue_elems' at
> > ../lib/ring/rte_ring_elem_pvt.h:132:3,
> >     inlined from '__rte_ring_do_hts_enqueue_elem' at
> > ../lib/ring/rte_ring_hts_elem_pvt.h:196:3,
> >     inlined from 'rte_ring_mp_hts_enqueue_bulk_elem' at
> > ../lib/ring/rte_ring_hts.h:56:9,
> >     inlined from 'rte_ring_enqueue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:208:10,
> >     inlined from 'rte_ring_enqueue_elem' at ../lib/ring/rte_ring_elem.h:290:9,
> >     inlined from 'rte_ring_enqueue' at ../lib/ring/rte_ring.h:339:9,
> >     inlined from '_cancel_producer' at
> > ../app/test/test_event_timer_adapter.c:834:10:
> > ../lib/ring/rte_ring_elem_pvt.h:100:25: error: 'memcpy' reading 32
> > bytes from a region of size 8 [-Werror=stringop-overread]
> >   100 |                         memcpy((void *)(ring + idx),
> >       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   101 |                                 (const void *)(obj + i), 32);
> >       |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ../app/test/test_event_timer_adapter.c: In function '_cancel_producer':
> > ../app/test/test_event_timer_adapter.c:805:1: note: source object
> > 'obj' of size 8
> >   805 | _cancel_producer(uint64_t timeout_tcks, uint64_t timers)
> >       | ^~~~~~~~~~~~~~~~
> > In function '__rte_ring_dequeue_elems_128',
> >     inlined from '__rte_ring_dequeue_elems' at
> > ../lib/ring/rte_ring_elem_pvt.h:262:3,
> >     inlined from '__rte_ring_do_dequeue_elem' at
> > ../lib/ring/rte_ring_elem_pvt.h:375:2,
> >     inlined from 'rte_ring_mc_dequeue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:320:9,
> >     inlined from 'rte_ring_dequeue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:381:10,
> >     inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
> >     inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
> >     inlined from '_cancel_thread' at
> > ../app/test/test_event_timer_adapter.c:917:7:
> > ../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
> > bytes into a region of size 8 overflows the destination
> > [-Werror=stringop-overflow=]
> >   234 |                         memcpy((void *)(obj + i), (void
> > *)(ring + idx), 32);
> >       |
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
> > ../app/test/test_event_timer_adapter.c:913:33: note: destination
> > object 'ev_tim' of size 8
> >   913 |         struct rte_event_timer *ev_tim = NULL;
> >       |                                 ^~~~~~
> > In function '__rte_ring_dequeue_elems_128',
> >     inlined from '__rte_ring_dequeue_elems' at
> > ../lib/ring/rte_ring_elem_pvt.h:262:3,
> >     inlined from '__rte_ring_do_dequeue_elem' at
> > ../lib/ring/rte_ring_elem_pvt.h:375:2,
> >     inlined from 'rte_ring_sc_dequeue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:348:9,
> >     inlined from 'rte_ring_dequeue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:384:10,
> >     inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
> >     inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
> >     inlined from '_cancel_thread' at
> > ../app/test/test_event_timer_adapter.c:917:7:
> > ../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
> > bytes into a region of size 8 overflows the destination
> > [-Werror=stringop-overflow=]
> >   234 |                         memcpy((void *)(obj + i), (void
> > *)(ring + idx), 32);
> >       |
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
> > ../app/test/test_event_timer_adapter.c:913:33: note: destination
> > object 'ev_tim' of size 8
> >   913 |         struct rte_event_timer *ev_tim = NULL;
> >       |                                 ^~~~~~
> > In function '__rte_ring_dequeue_elems_128',
> >     inlined from '__rte_ring_dequeue_elems' at
> > ../lib/ring/rte_ring_elem_pvt.h:262:3,
> >     inlined from '__rte_ring_do_rts_dequeue_elem' at
> > ../lib/ring/rte_ring_rts_elem_pvt.h:252:3,
> >     inlined from 'rte_ring_mc_rts_dequeue_bulk_elem' at
> > ../lib/ring/rte_ring_rts.h:110:9,
> >     inlined from 'rte_ring_dequeue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:387:10,
> >     inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
> >     inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
> >     inlined from '_cancel_thread' at
> > ../app/test/test_event_timer_adapter.c:917:7:
> > ../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
> > bytes into a region of size 8 overflows the destination
> > [-Werror=stringop-overflow=]
> >   234 |                         memcpy((void *)(obj + i), (void
> > *)(ring + idx), 32);
> >       |
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
> > ../app/test/test_event_timer_adapter.c:913:33: note: destination
> > object 'ev_tim' of size 8
> >   913 |         struct rte_event_timer *ev_tim = NULL;
> >       |                                 ^~~~~~
> > In function '__rte_ring_dequeue_elems_128',
> >     inlined from '__rte_ring_dequeue_elems' at
> > ../lib/ring/rte_ring_elem_pvt.h:262:3,
> >     inlined from '__rte_ring_do_hts_dequeue_elem' at
> > ../lib/ring/rte_ring_hts_elem_pvt.h:237:3,
> >     inlined from 'rte_ring_mc_hts_dequeue_bulk_elem' at
> > ../lib/ring/rte_ring_hts.h:83:9,
> >     inlined from 'rte_ring_dequeue_bulk_elem' at
> > ../lib/ring/rte_ring_elem.h:390:10,
> >     inlined from 'rte_ring_dequeue_elem' at ../lib/ring/rte_ring_elem.h:475:9,
> >     inlined from 'rte_ring_dequeue' at ../lib/ring/rte_ring.h:477:9,
> >     inlined from '_cancel_thread' at
> > ../app/test/test_event_timer_adapter.c:917:7:
> > ../lib/ring/rte_ring_elem_pvt.h:234:25: error: 'memcpy' writing 32
> > bytes into a region of size 8 overflows the destination
> > [-Werror=stringop-overflow=]
> >   234 |                         memcpy((void *)(obj + i), (void
> > *)(ring + idx), 32);
> >       |
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ../app/test/test_event_timer_adapter.c: In function '_cancel_thread':
> > ../app/test/test_event_timer_adapter.c:913:33: note: destination
> > object 'ev_tim' of size 8
> >   913 |         struct rte_event_timer *ev_tim = NULL;
> >       |                                 ^~~~~~
> > cc1: all warnings being treated as errors
> > ninja: subcommands failed
> >
> >
> > This is gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924.
> >
> > The compiler seems unhappy about the rte_int128_t type.
> > The below hunk seems to (confuse?) help the compiler.
> >
> > diff --git a/lib/ring/rte_ring_elem_pvt.h b/lib/ring/rte_ring_elem_pvt.h
> > index 83788c56e6..ece937f8e1 100644
> > --- a/lib/ring/rte_ring_elem_pvt.h
> > +++ b/lib/ring/rte_ring_elem_pvt.h
> > @@ -98,7 +98,7 @@ __rte_ring_enqueue_elems_128(struct rte_ring *r,
> > uint32_t prod_head,
> >      if (likely(idx + n <= size)) {
> >          for (i = 0; i < (n & ~0x1); i += 2, idx += 2)
> >              memcpy((void *)(ring + idx),
> > -                (const void *)(obj + i), 32);
> > +                (const void *)((uintptr_t)obj + i), 32);
> >          switch (n & 0x1) {
> >          case 1:
> >              memcpy((void *)(ring + idx),
> > @@ -231,7 +231,7 @@ __rte_ring_dequeue_elems_128(struct rte_ring *r,
> > uint32_t prod_head,
> >      rte_int128_t *obj = (rte_int128_t *)obj_table;
> >      if (likely(idx + n <= size)) {
> >          for (i = 0; i < (n & ~0x1); i += 2, idx += 2)
> > -            memcpy((void *)(obj + i), (void *)(ring + idx), 32);
> > +            memcpy((void *)((uintptr_t)obj + i), (void *)(ring + idx), 32);
> >          switch (n & 0x1) {
> >          case 1:
> >              memcpy((void *)(obj + i), (void *)(ring + idx), 16);
> >
> >
> > RTE_PTR_ADD has the same effect.
> >
> 
> This seems what Kevin had worked around for 21.11 release:
> https://inbox.dpdk.org/stable/20221220123754.239802-1-ktraynor@redhat.com/
> 
> I would tend to do the same and disable this warning for rc3 at least,
> and have stable branches and the main repository aligned.
> We can have a better fix later.
> 
> Opinions?
> 
No objections.

RE: Meson buildtype for ci jobs?

[Richardson, Bruce]

[-- Attachment #1: Type: text/plain, Size: 4544 bytes --]

The difference between release + debug and “debugoptimized” is that the former is “-O3 -g” while the latter is “-O2 -g”. The buildtypes are just shortcuts for setting optimization level and debug flags, and release is -O3 only flag.

From: Patrick Robb <probb@iol.unh.edu>
Sent: Wednesday, March 15, 2023 7:14 PM
To: Richardson, Bruce <bruce.richardson@intel.com>
Cc: David Marchand <david.marchand@redhat.com>; ci@dpdk.org; Aaron Conole <aconole@redhat.com>; Thomas Monjalon <thomas@monjalon.net>
Subject: Re: Meson buildtype for ci jobs?

Would passing "-Ddebug=true" be better than changing the default buildtype?
It's possible to have a release build (i.e. O3 optimized) with debug info.

Strangely, even with -Ddebug true if I'm running buildtype "release" it returns the same warnings. I'm inferring from your comment that release optimization == debugoptimized optimization and debug behavior from -Ddebug=true == debug behavior from debugoptimized, so release buildtype + debug "should" have the same behavior as just setting buildtype debugoptimized, and yet...

I'll have to look into this a little more. Hopefully by the end I'll be like David and understand the relations between these flags better, hah.

On Wed, Mar 15, 2023 at 1:02 PM Richardson, Bruce <bruce.richardson@intel.com<mailto:bruce.richardson@intel.com>> wrote:


> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com<mailto:david.marchand@redhat.com>>
> Sent: Wednesday, March 15, 2023 4:08 PM
> To: Patrick Robb <probb@iol.unh.edu<mailto:probb@iol.unh.edu>>
> Cc: ci@dpdk.org<mailto:ci@dpdk.org>; Aaron Conole <aconole@redhat.com<mailto:aconole@redhat.com>>; Richardson, Bruce
> <bruce.richardson@intel.com<mailto:bruce.richardson@intel.com>>; Thomas Monjalon <thomas@monjalon.net<mailto:thomas@monjalon.net>>
> Subject: Re: Meson buildtype for ci jobs?
>
> On Wed, Mar 15, 2023 at 4:52 PM Patrick Robb <probb@iol.unh.edu<mailto:probb@iol.unh.edu>> wrote:
> >
> > Hello all,
> >
> > The lab recently received a request to re-enable Alpine compile jobs,
> which have been disabled for almost a year. In dry running the compile
> job, I noticed that it was failing. At the same time, David Marchand did
> an Alpine compile with Github Actions which was successful. It seems the
> source of the different behavior is the meson buildtype being used - the
> build script used by GHA sets meson buildtype to debugoptimized, whereas
> the script used by the community lab runs with buildtype debug (the meson
> default). I did my own Github Actions runs (with both buildtype options)
> to sanity check:
> https://github.com/PatrickRobbIOL/dpdk/actions/runs/4427160204/jobs/776436
> 8640
>
> Are you sure about the default value?
>
> Afaics, meson selects by default a "release" buildtype (and I think I
> always saw this value in the past).
> I have this with meson 1.0.
>
> $ meson setup qsdlgfh
> ...
> $ meson configure qsdlgfh | grep buildtype
>   buildtype                      release
> [plain, debug, debugoptimized,   Build type to use
>
> >
> > The reason I'm writing this email is that I'm wondering whether the
> buildtype decision made by those who wrote .ci/linux-build.sh for GHA was
> intentional and important. I know many of the people who have commits on
> that script follow this mailing list. Obviously if it's in some way more
> appropriate for CI purposes to run meson setup in this way, I'm happy to
> make that change at the lab and in the process that would free up bringing
> Alpine compile testing online. But, if not, then I think it's most
> appropriate to consider compile on Alpine as broken and avoid bringing
> coverage for Alpine online until that issue is resolved.
>
> The reason why we went with debugoptimized was primarly for the ABI
> checks, as by default, the debug symbols were missing (which would
> match with a "release" default buildtype).
> See 777014e56d07 ("devtools: add ABI checks").
>

Would passing "-Ddebug=true" be better than changing the default buildtype?
It's possible to have a release build (i.e. O3 optimized) with debug info.

/Bruce


--

Patrick Robb

Technical Service Manager

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

www.iol.unh.edu<http://www.iol.unh.edu/>



[https://lh4.googleusercontent.com/7sTY8VswXadak_YT0J13osh5ockNVRX2BuYaRsKoTTpkpilBokA0WlocYHLB4q7XUgXNHka6-ns47S8R_am0sOt7MYQQ1ILQ3S-P5aezsrjp3-IsJMmMrErHWmTARNgZhpAx06n2]

[-- Attachment #2: Type: text/html, Size: 9980 bytes --]