DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Varghese, Vipin" <vipin.varghese@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	"Hunt, David" <david.hunt@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Patel, Amol" <amol.patel@intel.com>
Subject: Re: [dpdk-dev] [PATCH v1] mk: allow use of toolchain cflags
Date: Tue, 7 Nov 2017 00:15:37 +0000	[thread overview]
Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D168836@BGSMSX101.gar.corp.intel.com> (raw)
In-Reply-To: <2369574.SFH6e9u1pT@xps>

Hi Thomas,

Please find my answers below 

Why do you want to use export from the shell environment?
Answer> One scenario that generic scripts or makefiles are used to build DPDK and Customer components. While building for "make debug" mode; we require DPDK libraries to be built with compiler specific additives. Hence there are requirements of having them exported (especially in DPDK shared library mode) is in practice.

The standard way of overriding a variable with make, is to specify a value on the make command line.
Answer> Please find my observations while using non modified DPDK versions

CMD: 
1) cd $RTE_SDK/$RTE_TARGET
2) make clean; make TOOLCHAIN_CFLAGS="-ggdb -fno-omit-frame-pointer"

Checking for user flags:
# grep -nr "fno-omit-frame-pointer" lib/ | wc -l
	66
<these were not expected>
# grep -nr "fno-omit-frame-pointer" app/
	Binary file app/dpdk-procinfo matches
	Binary file app/testpmd matches
	Binary file app/dpdk-test-eventdev matches
	Binary file app/dpdk-test-crypto-perf matches
	Binary file app/dpdk-pdump matches
# grep -nr "fno-omit-frame-pointer" kmod/
<confirming application are shared library, hence code segment should not have been built with these flags>
# ldd x86_64-native-linuxapp-gcc/app/* | grep rte_eal
        	librte_eal.so.5.1 => /home/saesrv02/Downloads/dpdksrc/dpdk-17.08/x86_64-native-linuxapp-gcc/lib/librte_eal.so.5.1 (0x00007f9a7badc000)
        	librte_eal.so.5.1 => /home/saesrv02/Downloads/dpdksrc/dpdk-17.08/x86_64-native-linuxapp-gcc/lib/librte_eal.so.5.1 (0x00007fb2fb318000)
        	librte_eal.so.5.1 => /home/saesrv02/Downloads/dpdksrc/dpdk-17.08/x86_64-native-linuxapp-gcc/lib/librte_eal.so.5.1 (0x00007f865530f000)
        	librte_eal.so.5.1 => /home/saesrv02/Downloads/dpdksrc/dpdk-17.08/x86_64-native-linuxapp-gcc/lib/librte_eal.so.5.1 (0x00007f83c7c4c000)
        	librte_eal.so.5.1 => /home/saesrv02/Downloads/dpdksrc/dpdk-17.08/x86_64-native-linuxapp-gcc/lib/librte_eal.so.5.1 (0x00007f1003c10000)

If you really want to take environment value into account, you can just comment this assignment or use ?= operator.
Answer> I also tried adding variable into ".config" - "CONFIG_RTE_TOOLCHAIN_GCC_DEBUG=y", then manually editing "mk/toolchain/gcc/rte.vars.mk" as "ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC_DEBUG),y) TOOLCHAIN_CFLAGS ?= <my desired flags>". But this requires to edit or sed the file for each new combination. Hence dropped this approach.

Note that you can also use EXTRA_CFLAGS.
Answer> As per the mailing list http://dpdk.org/ml/archives/dev/2015-August/022592.html, passing EXTRA_CFLAGS will solve the issue. But this affect modules, libraries and application
grep -nr EXTRA_CFLAGS * --include=*.mk
internal/rte.compile-pre.mk:78: $(CFLAGS_$(@)) $(HOST_EXTRA_CPPFLAGS) $(HOST_EXTRA_CFLAGS) -o $@ -c $<
internal/rte.compile-pre.mk:83: $(CFLAGS_$(@)) $(EXTRA_CPPFLAGS) $(EXTRA_CFLAGS) -o $@ -c $<
rte.app.mk:245:O_TO_EXE = $(CC) -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $(OBJS-y) $(call linkerprefix, \
rte.bsdmodule.mk:34:override EXTRA_CFLAGS = $(MODULE_CFLAGS) $(EXTRA_KERNEL_CFLAGS)
rte.cpuflags.mk:36:AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(WERROR_FLAGS) $(EXTRA_CFLAGS) -dM -E - < /dev/null)
rte.lib.mk:80:LD := $(CC) $(CPU_CFLAGS) $(EXTRA_CFLAGS)
rte.module.mk:34:override EXTRA_CFLAGS = $(MODULE_CFLAGS) $(EXTRA_KERNEL_CFLAGS)
toolchain/gcc/rte.vars.mk:69:ifeq (,$(findstring -O0,$(EXTRA_CFLAGS)))
toolchain/gcc/rte.vars.mk:70: $(warning "EXTRA_CFLAGS doesn't contains -O0, coverage will be inaccurate with optimizations enabled")

I would be in favor of removing these variables.
We have too many variables.
Answer> Ok, at least we should have right variables to allow build components with right settings.

Thanks
Vipin Varghese

-----Original Message-----
From: Thomas Monjalon [mailto:thomas@monjalon.net] 
Sent: Tuesday, November 7, 2017 2:38 AM
To: Hunt, David <david.hunt@intel.com>; Varghese, Vipin <vipin.varghese@intel.com>
Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [PATCH v1] mk: allow use of toolchain cflags

03/11/2017 10:40, David Hunt:
> From: Vipin Varghese <vipin.varghese@intel.com>
> 
> with 'export TOOLCHAIN_CFLAGS' the values are not inherited throuhout 
> make system. The change appends the user defined cflags.

Why do you want to use export from the shell environment?
The standard way of overriding a variable with make, is to specify a value on the make command line.

[...]
> -TOOLCHAIN_ASFLAGS =
> -TOOLCHAIN_CFLAGS =
> -TOOLCHAIN_LDFLAGS =
> +TOOLCHAIN_ASFLAGS +=
> +TOOLCHAIN_CFLAGS +=
> +TOOLCHAIN_LDFLAGS +=

There is nothing to append here.
It is here only for documentation purpose.
If you really want to take environment value into account, you can just comment this assignment or use ?= operator.

Note that you can also use EXTRA_CFLAGS.
I would be in favor of removing these variables.
We have too many variables.

      reply	other threads:[~2017-11-07  0:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-03  9:40 David Hunt
2017-11-06 21:07 ` Thomas Monjalon
2017-11-07  0:15   ` Varghese, Vipin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C9E0AB70F954A408CC4ADDBF0F8FA7D4D168836@BGSMSX101.gar.corp.intel.com \
    --to=vipin.varghese@intel.com \
    --cc=amol.patel@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.hunt@intel.com \
    --cc=dev@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).