New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 771974 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

See about using build system BUILD_CFLAGS for kernel

Project Member Reported by diand...@chromium.org, Oct 5 2017

Issue description

In <http://crosreview.com/696186/> we're setting up HOSTCC from the build system but not the CFLAGS.

We should pass the CFLAGS too.

...for target code we argued (http://crosreview.com/696185/) that we should ignore the build system's CFLAGS, but that argument doesn't really make a lot of sense for host code.

NOTE: I _think_ we'll need to make UPSTREAM changes to the kernel to support this.
 
FWIW, I tried passing BUILD_CFLAGS as HOST_CFLAGS. If I recall correctly this worked fine.

> FWIW, I tried passing BUILD_CFLAGS as HOST_CFLAGS. If I recall correctly this worked fine.

Well, it doesn't cause compile errors.  ...but as far as I can tell it doesn't actually do what you expect.  I put printouts in the kernel:

---

diff --git a/Makefile b/Makefile
index 7f96567a6d03..8a0e567f18b6 100644
--- a/Makefile
+++ b/Makefile
@@ -299,16 +299,23 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
          else if [ -x /bin/bash ]; then echo /bin/bash; \
          else echo sh; fi ; fi)
 
+$(info HOSTCFLAGS 1 $(HOSTCFLAGS))
+
 HOSTCC       = gcc
 HOSTCXX      = g++
 HOSTCFLAGS   := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
 HOSTCXXFLAGS = -O2
 
+$(info HOSTCFLAGS 2 $(HOSTCFLAGS))
+
 ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
 HOSTCFLAGS  += -Wno-unused-value -Wno-unused-parameter \
                -Wno-missing-field-initializers -fno-delete-null-pointer-checks
 endif
 
+$(info HOSTCFLAGS 3 $(HOSTCFLAGS))
+$(error done)
+
 # Decide whether to build built-in, modular, or both.
 # Normally, just do built-in.
 
---

When I did that I saw:

HOSTCFLAGS 1 -O1 -pipe
HOSTCFLAGS 2 -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
HOSTCFLAGS 3 -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89

...in other words the "-O1" and "-pipe" got clobbered.

---

I believe that we just need to change the initial setting of HOSTCFLAGS and HOSTCXXFLAGS:

-HOSTCFLAGS   := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
-HOSTCXXFLAGS = -O2
+HOSTCFLAGS   += -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
+HOSTCXXFLAGS += -O2


...but I think I owe Masahiro Yamada a review of his patches before I ask him to review another of mine.  I'll see if I can get to that in the next day or two.
Components: OS>Kernel
Cc: manojgupta@chromium.org
We'll see what upstream says: 

https://patchwork.kernel.org/patch/10005567/
Status: WontFix (was: Untriaged)
Upstream isn't against this but wants a compelling reason why we need it before landing it.  At the moment I don't have a compelling raeason since all of the HOST CFLAGS are non-critical.  

If anyone has any compelling reasons then feel free to post upstream or post here and I'll pass them along.  Barring that I'm making this as WontFix.  If we ever find a compelling reason why we need to do this then we can always resurrect this bug.

Sign in to add a comment