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

[David Marchand]

On Mon, Jul 1, 2019 at 5:30 PM Ferruh Yigit <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>> 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?


-- 
David Marchand