On 02-May-19 7:54 PM, Stephen Hemminger wrote:
On Thu, 2 May 2019 16:53:50 +0100
"Burakov, Anatoly" <anatoly.bura...@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
