Skip to contentSkip to conversation

clang build failing in v2.0.0 from poisoned symbols

DISCUSSION Matthew Hall 2 participants 5 messages Jun 19, 2015 – Jun 22, 2015 1 message not in the archive

lore
Share & tools
lore
#0 lore raw

Hi all,

I am getting some odd behavior compiling the DPDK v2.0.0 tag with clang:

/* deprecated options */
#pragma GCC poison RTE_MBUF_SCATTER_GATHER
#pragma GCC poison RTE_MBUF_REFCNT

In file included from dpdk/lib/librte_mbuf/rte_mbuf.c:58:

dpdk/lib/librte_mbuf/rte_mbuf.h:68:20: error: poisoning existing macro [-Werror]

So I was reading about all of this and it was clear what poisoning is for, but it wasn't as clear what I should do about this error on the clang side. I tried searching the archive for "clang poison" but I didn't get much.

Any advice for this?

Thanks,
Matthew

#1 lore raw
Quoted 1 line · Matthew Hall

dpdk/lib/librte_mbuf/rte_mbuf.h:68:20: error: poisoning existing macro [-Werror]

Hi all,

I finally figured out what happened. My older DPDK build configuration file had defined the poisoned macros to try to enable the features they used to cover, which had been obsoleted and/or replaced.

I am happy to be able to report that my app compiled with no changes once I rebased my locally tweaked DPDK onto the v2.0.0 tag... very impressive work... we might not be binary compatible but we definitely seem to be source compatible for my app at least. Considering most people use the static library this is not a bad state to start with I'd say.

Matthew.

#2 lore raw
Quoted 9 lines · Matthew Hall
Quoted 1 line · Matthew Hall

dpdk/lib/librte_mbuf/rte_mbuf.h:68:20: error: poisoning existing macro [-Werror]

Hi all,

I finally figured out what happened. My older DPDK build configuration file had defined the poisoned macros to try to enable the features they used to cover, which had been obsoleted and/or replaced.

Quoted 7 lines

I am happy to be able to report that my app compiled with no changes once I rebased my locally tweaked DPDK onto the v2.0.0 tag... very impressive work... we might not be binary compatible but we definitely seem to be source compatible for my app at least. Considering most people use the static library this is not a bad state to start with I'd say.

Matthew.

Thank you. It's finally nice to get some good news about compatibility! :-)

#3 lore raw

Re: DPDK v2.0.0 has different rte_eal_pci_probe() behavior

Quoted 1 line · Bruce Richardson

Thank you. It's finally nice to get some good news about compatibility! :-)

Hi Bruce,

I did manage to find just one weird issue when I was trying to use the new DPDK v2.0.0. Previously I had code which was calling rte_eal_pci_probe() after rte_eal_init, rte_set_log_level, rte_mempool_create steps were completed, based on some of the sample applications. However it seems like the new code is calling this function itself inside of rte_eal_init.

So then the second call to it from my application raises some pretty odd errors and causes DPDK to terminate because it was one of the whitelisted PCI devices which is considered mandatory to succeed in the init process:

EAL: PCI device 0000:00:09.0 on NUMA socket -1
EAL:   probe driver: 8086:100e rte_em_pmd
EAL:   PCI memory mapped at 0x7ff0dc200000
PMD: eth_em_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x100e
EAL: PCI device 0000:00:09.0 on NUMA socket -1
EAL:   probe driver: 8086:100e rte_em_pmd
EAL:   PCI memory mapped at 0x7ff0dc220000
EAL: Error - exiting with code: 1

Cause: Requested device 0000:00:09.0 cannot be used

I am not sure if it means I screwed up and wasn't doing it right in the first place and it was always incorrect to do it the way I did or if this is a behavior change that should be documented somewhere. Has anybody else seen this behavior?

Matthew.

A message that is not in the archive (sent off-list or not yet received): CAO1kT8_C2QJUrNk-fqOQd=WmOkpvNw5jCvxEhfPdHwyCwBuyKA@mail.gmail.com

#5 lore raw

Re: DPDK v2.0.0 has different rte_eal_pci_probe() behavior

Quoted 7 lines · Tom Barbette

Application call to rte_eal_pci_probe() is not needed anymore since DPDK 1.8.

http://dpdk.org/ml/archives/dev/2014-September/005890.html

You were not wrong before, it is just a change in DPDK. I came across the same problem a few days ago.

Tom Barbette

So, we have a good practical example below about ABI compatibility.

The prototype and name of the rte_eal_pci_probe() was kept exactly the same, and it compiled fine with no change, but it fails at runtime because it causes a dual-init of all the PCI devices and hits a resource conflict in the process.

Thus it's important to remember you can break compatibility even if the ABI stays the same, if the APIs themselves don't behave the same over time...

Matthew.