[dpdk-dev] [PATCH v2 00/10] experimental tags fixes

[Ferruh Yigit]

On 7/1/2019 8:27 PM, David Marchand wrote:
> 
> 
> On Mon, Jul 1, 2019 at 5:30 PM Ferruh Yigit <ferruh.yigit at intel.com
> <mailto:ferruh.yigit at intel.com>> wrote:
> 
>     On 7/1/2019 3:36 PM, David Marchand wrote:
>     >
>     >
>     > On Mon, Jul 1, 2019 at 4:15 PM Ferruh Yigit <ferruh.yigit at intel.com
>     <mailto:ferruh.yigit at intel.com>
>     > <mailto:ferruh.yigit at intel.com <mailto:ferruh.yigit at intel.com>>> wrote:
>     >
>     >     On 6/29/2019 6:06 PM, Thomas Monjalon wrote:
>     >     > 29/06/2019 13:58, David Marchand:
>     >     >> Following the build error reported by Aaron [1], I noticed that some
>     >     >> experimental functions could go unnoticed because of a gcc peculiarity.
>     >     >>
>     >     >> To catch those, I went and added a new check on the object files to
>     >     >> ensure that any experimental api flagged in the map files is really
>     >     >> exported as such.
>     >     >>
>     >     >> Then went with my previous idea of only adding the tags on the
>     functions
>     >     >> prototypes and enforcing it (a new check in checkpatches.sh).
>     >     >> And finally enforcing that the __rte_experimental tag is always the
>     first
>     >     >> part of a function prototype which seems to work with both gcc and
>     clang.
>     >     >
>     >     > Applied, thanks
>     >     >
>     >
>     >
>     >     Getting an odd build error with "i686-native-linuxapp-icc" [1].
>     >     Beware of the "." at the end: "rte_flow_conv."
>     >
>     >     Objdump shows two symbols with one "." at the end and one without it [2].
>     >
>     >     And this seems not the problem of only experimental APIs [3]. But this
>     is only
>     >     happening with "i686-native-linuxapp-icc".
>     >
>     >     Do you have any idea what is going on here?
>     >
>     >
>     > Looked at rte_flow_conv, and I can not see anything special about it.
>     >
>     > There might be a subtility in the way symbol names are chosen by ICC.
>     > Can ICC guys look at this and give us some enlightment?
> 
>     This is the sample disassembler of one of the "." functions [1], it looks like
>     this notation is used by compiler to prepend some code at the very begging of
>     the function, Harry (cc'ed) let me know this is may be security feature, not a
>     defect of compiler :)
> 
>     So briefly, it looks like compiler can add this "." version of the symbols to
>     the ".text.experimental" section, I believe the solution is detect this notation
>     and handle it. What do you think?
> 
> 
> Iiuc, we would skip the symbols finishing with a '.', is this all?
> 

yes