On Mon, Jul 1, 2019 at 5:30 PM Ferruh Yigit <ferruh.yi...@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.yi...@intel.com > > <mailto:ferruh.yi...@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
