[dpdk-dev] [PATCH] Enable AddressSanitizer feature on DPDK

Stephen Hemminger stephen at networkplumber.org
Mon Sep 13 17:05:58 CEST 2021


On Mon, 13 Sep 2021 05:27:12 +0000
"Peng, ZhihongX" <zhihongx.peng at intel.com> wrote:

> > -----Original Message-----
> > From: Stephen Hemminger <stephen at networkplumber.org>
> > Sent: Friday, September 10, 2021 10:48 AM
> > To: Peng, ZhihongX <zhihongx.peng at intel.com>
> > Cc: Burakov, Anatoly <anatoly.burakov at intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev at intel.com>; dev at dpdk.org; Lin, Xueqin
> > <xueqin.lin at intel.com>
> > Subject: Re: [PATCH] Enable AddressSanitizer feature on DPDK
> > 
> > On Fri, 10 Sep 2021 02:01:47 +0000
> > zhihongx.peng at intel.com wrote:
> >   
> > >
> > > +if get_option('b_sanitize').startswith('address')
> > > +	cflags += '-DRTE_MALLOC_ASAN'
> > > +endif
> > > +  
> > 
> > This looks great, but can we make it just do-the-right-thing and get rid of the
> > nerd knobs (i.e no meson configure).
> > 
> > The address sanitizer already has a way to detect if enabled.
> > 
> > GCC uses:
> > __SANITIZE_ADDRESS__
> > 
> > Clang uses:
> > #if defined(__has_feature)
> > #  if __has_feature(address_sanitizer)  
> 
> Tried this method you said. It can run successfully. Because gcc and clang have different
> Methods for determining whether to turn on the asan function, so if you judge the two
> methods in the code, it feels not simple to judge in meson.

There is already compiler specific #ifdef's why not do this contained in one header file?

The point is DPDK is trying to get away from having configuration settings if at all
possible. Configuration creates dependency nightmares and also leaves many code paths
as never tested.


More information about the dev mailing list