[dpdk-dev] [PATCH v2] mk: report address of packed member as warning

[Burakov, Anatoly]

On 02-May-19 7:54 PM, Stephen Hemminger wrote:
> On Thu, 2 May 2019 16:53:50 +0100
> "Burakov, Anatoly" <anatoly.burakov at intel.com> wrote:
> 
>> On 02-May-19 3:13 PM, Reshma Pattan wrote:
>>> gcc 9 on Fedora 30 gives an error
>>> "taking address of packed member may result in an
>>> unaligned pointer value" for -Waddress-of-packed-member.
>>>
>>> Report it as warning instead of error to fix the build.
>>>
>>> Snippet of build before fix
>>> ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
>>> ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
>>> of packed member of ‘struct rte_mem_config’ may result in an unaligned
>>> pointer value [-Werror=address-of-packed-member]
>>>     768 |  cur_msl = &mcfg->memsegs[msl_idx];
>>>         |            ^~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> Snippet of build after fix
>>> ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
>>> ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
>>> of packed member of ‘struct rte_mem_config’ may result in an unaligned
>>> pointer value [-Waddress-of-packed-member]
>>>     685 |   msl = &mcfg->memsegs[msl_idx];
>>>    
>>
>> Fixing these would require an ABI break, because these are exposed
>> externally. Should we submit a deprecation notice for EAL?
> 
> 
> Ideally mem config and related structures would not be exposed in the
> API. Like lcore_config and eal_config it should be eal_private
> 

In a perfect world, that would've been the case. However, these are in 
shared memory structures that are used for multiprocess synchronization.

-- 
Thanks,
Anatoly