The "-Wimplicit-fallthrough=2" option was introduced into gcc 7.0, it was
enabled when the cross compiler gcc is greater than 7.0, but for the host
side buildtools/pmdinfogen, if the native gcc is older than 7.0, or the
host cc compiler is clang, it should not be enabled.
The fix is to differentiate the host gcc Werror options from the cross gcc.
gcc -Wp,-MD,./.pmdinfogen.o.d.tmp -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wold-style-definition
-Wpointer-arith -Wcast-align -Wnested-externs -Wcast-qual
-Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings -Wdeprecated
-Werror -Wimplicit-fallthrough=2 -Dbbb -Wno-format-truncation -g
-I/dpdk/build/include -o pmdinfogen.o -c
~/dpdk/buildtools/pmdinfogen/pmdinfogen.c gcc: error:
unrecognized command line option ‘-Wimplicit-fallthrough=2’
Fixes: ced3e6f8 ("mk: adjust gcc flags for new gcc 7 warnings")
Cc: stable@dpdk.org
Signed-off-by: Gavin Hu <gavin.hu@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Steve Capper <steve.capper@arm.com>
Tested-by: Ali Alnubani <alialnu@mellanox.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Before this patch, the management of dependencies between directories
had several issues:
- the generation of .depdirs, done at configuration is slow: it can take
more than one minute on some slow targets (usually ~10s on a standard
PC without -j).
- for instance, it is possible to express a dependency like:
- app/foo depends on lib/librte_foo
- and lib/librte_foo depends on app/bar
But this won't work because the directories are traversed with a
depth-first algorithm, so we have to choose between doing 'app' before
or after 'lib'.
- the script depdirs-rule.sh is too complex.
- we cannot use "make -d" for debug, because the output of make is used for
the generation of .depdirs.
This patch moves the DEPDIRS-* variables in the upper Makefile, making
the dependencies much easier to calculate. A DEPDIRS variable is still
used to process library dependencies in LDLIBS.
After this commit, "make config" is almost immediate.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Tested-by: Robin Jarry <robin.jarry@6wind.com>
Tested-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
The following tools may be installed system-wide.
It may be cleaner and more convenient to find them with the same
dpdk- prefix (especially for autocompletion).
Moreover, the script dpdk_nic_bind.py deserves a new name because it is
not restricted to NICs and can be used for e.g. crypto.
These files are renamed:
pmdinfogen -> dpdk-pmdinfogen
pmdinfo.py -> dpdk-pmdinfo.py
dpdk_pdump -> dpdk-pdump
dpdk_proc_info -> dpdk-procinfo
dpdk_nic_bind.py -> dpdk-devbind.py
setup.sh -> dpdk-setup.sh
The tools pmdinfogen, pmdinfo.py and dpdk_pdump are new in 16.07.
The scripts dpdk_nic_bind.py and setup.sh may have been used with
previous releases by end users. That's why a symbolic link still
provide the old name in the installed tools directory.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
When compiled with a standard clang, pmdinfogen can raise a warning:
buildtools/pmdinfogen/pmdinfogen.c:365:1: warning:
control reaches end of non-void function
Actually there can be more warnings with stricter compilers.
In order to catch them early and fix most of them, the DPDK standard flags
WERROR_FLAGS are used.
The warnings fixed are:
no previous prototype for ...
no return statement in function returning non-void
variable ‘secstrings’ set but not used
‘sec_name’ defined but not used
‘get_symbol_index’ defined but not used
pointer of type ‘void *’ used in arithmetic
Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility")
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
pmdinfogen is a tool used to parse object files and build json strings for
use in later determining hardware support in a dso or application binary.
pmdinfo looks for the non-exported symbol names this_pmd_name<n> and
this_pmd_tbl<n> (where n is a integer counter). It records the name of
each of these tuples, using the later to find the symbolic name of the
pci_table for physical devices that the object supports. With this
information, it outputs a C file with a single line of the form:
static char *<pmd_name>_driver_info[] __attribute__((used)) = " \
PMD_DRIVER_INFO=<json string>";
Where <pmd_name> is the arbitrary name of the pmd, and <json_string> is the
json encoded string that hold relevant pmd information, including the pmd
name, type and optional array of pci device/vendor ids that the driver
supports.
This c file is suitable for compiling to object code, then relocatably
linking into the parent file from which the C was generated. This creates
an entry in the string table of the object that can inform a later tool
about hardware support.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Panu Matilainen <pmatilai@redhat.com>
Acked-by: Remy Horton <remy.horton@intel.com>
