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

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 7/1/2019 3:36 PM, David Marchand wrote:
> 
> 
> On Mon, Jul 1, 2019 at 4:15 PM Ferruh Yigit <ferruh.yigit@intel.com
> <mailto:ferruh.yigit@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?



[1]
00002070 <rte_eth_promiscuous_enable>:
    2070:       0f b7 44 24 04          movzwl 0x4(%esp),%eax

00002075 <rte_eth_promiscuous_enable.>:
    2075:       56                      push   %esi
    2076:       57                      push   %edi
    2077:       83 ec 14                sub    $0x14,%esp
    207a:       0f b7 c0                movzwl %ax,%eax
    207d:       83 f8 20                cmp    $0x20,%eax
    2080:       7d 14                   jge    2096
<rte_eth_promiscuous_enable.+0x21>
    2082:       8b f0                   mov    %eax,%esi
    2084:       8b f8                   mov    %eax,%edi
    2086:       c1 e6 06                shl    $0x6,%esi
    2089:       c1 e7 0d                shl    $0xd,%edi
    208c:       83 bc 3e 28 20 00 00    cmpl   $0x0,0x2028(%esi,%edi,1)
    2093:       00
    2094:       75 1c                   jne    20b2
<rte_eth_promiscuous_enable.+0x3d>
    2096:       50                      push   %eax
    2097:       68 00 00 00 00          push   $0x0
    209c:       ff 35 00 00 00 00       pushl  0x0
    20a2:       6a 04                   push   $0x4
    20a4:       e8 fc ff ff ff          call   20a5
<rte_eth_promiscuous_enable.+0x30>
    20a9:       83 c4 10                add    $0x10,%esp
....