Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace Bazel's custom unix_cc_configure with a wrapper script. #2631

Merged
merged 5 commits into from
Feb 20, 2018
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 38 additions & 47 deletions bazel/cc_configure.bzl
Original file line number Diff line number Diff line change
@@ -1,56 +1,48 @@
# This file was imported from https://github.com/bazelbuild/bazel at 3d00b2a. We apply a number of
# local modifications to deal with known issues in Bazel 0.10.0.
#
# * https://github.com/bazelbuild/bazel/issues/2840
# * (and potentially) https://github.com/bazelbuild/bazel/issues/2805
#
# See cc_configure.bzl.diff for the changes made in this fork.
load("@bazel_tools//tools/cpp:cc_configure.bzl", _upstream_cc_autoconf_impl = "cc_autoconf_impl")
load("@bazel_tools//tools/cpp:lib_cc_configure.bzl", "get_cpu_value")
load("@bazel_tools//tools/cpp:unix_cc_configure.bzl", "find_cc")

# Copyright 2016 The Bazel Authors. All rights reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
"""Rules for configuring the C++ toolchain (experimental)."""
def _quiet_fake_which(program):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add comments here and below providing details on why we're faking?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

return struct(_envoy_fake_which = program)

def _noisy_fake_which(program):
return None

load("@bazel_tools//tools/cpp:windows_cc_configure.bzl", "configure_windows_toolchain")
load("@bazel_tools//tools/cpp:osx_cc_configure.bzl", "configure_osx_toolchain")
load("//bazel:unix_cc_configure.bzl", "configure_unix_toolchain")
load("@bazel_tools//tools/cpp:lib_cc_configure.bzl", "get_cpu_value")
def _build_envoy_cc_wrapper(repository_ctx):
real_cc = find_cc(repository_ctx, {})
environ_cxx = repository_ctx.os.environ.get("CXX", "g++")
fake_os = struct(
environ = {"CC": environ_cxx},
)
real_cxx = find_cc(struct(
which = _quiet_fake_which,
os = fake_os,
), {})
if hasattr(real_cxx, "_envoy_fake_which"):
real_cxx = repository_ctx.which(real_cxx._envoy_fake_which)
if real_cxx == None:
find_cc(struct(
which = _noisy_fake_which,
os = fake_os,
), {})
repository_ctx.template("envoy_cc_wrapper", repository_ctx.attr._envoy_cc_wrapper, {
"{ENVOY_REAL_CC}": repr(str(real_cc)),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, definitely could do with a narrative explaining what's happening here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

"{ENVOY_REAL_CXX}": repr(str(real_cxx)),
})
return repository_ctx.path("envoy_cc_wrapper")

def cc_autoconf_impl(repository_ctx, overriden_tools = dict()):
repository_ctx.symlink(
Label("@bazel_tools//tools/cpp:dummy_toolchain.bzl"), "dummy_toolchain.bzl")
env = repository_ctx.os.environ
def cc_autoconf_impl(repository_ctx):
cpu_value = get_cpu_value(repository_ctx)
if cpu_value == "freebsd":
# This is defaulting to the static crosstool, we should eventually
# autoconfigure this platform too. Theorically, FreeBSD should be
# straightforward to add but we cannot run it in a docker container so
# skipping until we have proper tests for FreeBSD.
repository_ctx.symlink(Label("@bazel_tools//tools/cpp:CROSSTOOL"), "CROSSTOOL")
repository_ctx.symlink(Label("@bazel_tools//tools/cpp:BUILD.static"), "BUILD")
elif cpu_value == "x64_windows":
# TODO(ibiryukov): overriden_tools are only supported in configure_unix_toolchain.
# We might want to add that to Windows too(at least for msys toolchain).
configure_windows_toolchain(repository_ctx)
elif (cpu_value == "darwin" and
("BAZEL_USE_CPP_ONLY_TOOLCHAIN" not in env or env["BAZEL_USE_CPP_ONLY_TOOLCHAIN"] != "1")):
configure_osx_toolchain(repository_ctx, overriden_tools)
else:
configure_unix_toolchain(repository_ctx, cpu_value, overriden_tools)
overriden_tools = {}
if cpu_value not in ["freebsd", "x64_windows", "darwin"]:
overriden_tools["gcc"] = _build_envoy_cc_wrapper(repository_ctx)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is gcc hardcoded here? Is this generic $CC effectively? If so, why not on Darwin as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment. To Bazel, all CCs are GCC.

return _upstream_cc_autoconf_impl(repository_ctx, overriden_tools=overriden_tools)

cc_autoconf = repository_rule(
implementation = cc_autoconf_impl,
attrs = {
"_envoy_cc_wrapper": attr.label(default="@envoy//bazel:cc_wrapper.py"),
},
environ = [
"ABI_LIBC_VERSION",
"ABI_VERSION",
Expand All @@ -65,6 +57,7 @@ cc_autoconf = repository_rule(
"BAZEL_VC",
"BAZEL_VS",
"CC",
"CXX",
"CC_CONFIGURE_DEBUG",
"CC_TOOLCHAIN_NAME",
"CPLUS_INCLUDE_PATH",
Expand All @@ -82,8 +75,6 @@ cc_autoconf = repository_rule(
"VS120COMNTOOLS",
"VS140COMNTOOLS"])


def cc_configure():
"""A C++ configuration rules that generate the crosstool file."""
cc_autoconf(name="local_config_cc")
native.bind(name="cc_toolchain", actual="@local_config_cc//:toolchain")
33 changes: 0 additions & 33 deletions bazel/cc_configure.bzl.diff

This file was deleted.

54 changes: 54 additions & 0 deletions bazel/cc_wrapper.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
#!/usr/bin/python
import os
import sys
import tempfile

envoy_real_cc = {ENVOY_REAL_CC}
envoy_real_cxx = {ENVOY_REAL_CXX}

def sanitize_flagfile(in_path, out_fd):
with open(in_path, "rb") as in_fp:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 space indent, standard Google style for Python.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done with yapf -i --style '{based_on_style: google, indent_width: 2}' cc_wrapper.py

for line in in_fp:
if line != "-lstdc++\n":
os.write(out_fd, line)

def main():
compiler = envoy_real_cc

# Debian's packaging of Clang requires `-no-canonical-prefixes` to print
# consistent include paths, but Bazel 0.10 only sets that option at compile
# time. We inject it here for the configuration of `@local_config_cc//`.
#
# https://github.com/bazelbuild/bazel/issues/3977
# https://github.com/bazelbuild/bazel/issues/4572
# https://bazel-review.googlesource.com/c/bazel/+/39951
if sys.argv[1:] == ["-E", "-xc++", "-", "-v"] and "clang" in compiler:
os.execv(envoy_real_cxx, [envoy_real_cxx, "-E", "-", "-v", "-no-canonical-prefixes"])

# `g++` and `gcc -lstdc++` have similar behavior and Bazel treats them as
# interchangeable, but `gcc` will ignore the `-static-libstdc++` flag.
# This check lets Envoy statically link against libstdc++ to be more
# portable between intalled glibc versions.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: s/intalled/installed/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

if "-static-libstdc++" in sys.argv[1:]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you verified with ldd that we're still getting the desired static/dynamic link mix?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, libstdc++.so doesn't show up in the output of ldd bazel-bin/source/exe/envoy when using this wrapper.

compiler = envoy_real_cxx
argv = []
for arg in sys.argv[1:]:
if arg == "-lstdc++":
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to ensure that this is going to work with Envoy OSS-Fuzz that uses libc++, seehttps://github.com/google/oss-fuzz/tree/master/projects/envoy.

Can you checkout OSS-Fuzz (https://github.com/google/oss-fuzz) and run:

python infra/helper.py build_image envoy
python infra/helper.py build_fuzzers --sanitizer=address envoy <path to your Envoy source tree>
python infra/helper.py run_fuzzer envoy base64_fuzz_test

See https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#testing-locally for the official docs on this flow if you have issues, or reach out to me on Slack.

I think we should eventually put this in a CI slot to ensure we don't regress as we much with build, but for now we need to manually do this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running now. I've only got a laptop to build with so it's taking a pretty good amount of time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oss-fuzz works with the new script, but we need to add python to the Debian package lits in oss-fuzz/projects/envoy/Dockerfile.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correction: I ran the oss-fuzz script correctly this time (on my branch instead of envoy upstream) and it failed with some C++ stdlib linker problem. I think a -lstdc++ was getting through the wrapper somehow. Rebuilding now to see if more filtering fixed it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified it works once we add -stdlib=libc++ to the list of flags that need -lstdc++ to be pruned first.

pass
elif arg.startswith("-Wl,@"):
# tempfile.mkstemp will write to the out-of-sandbox tempdir
# unless the user has explicitly set environment variables
# before starting Bazel. But here in $PWD is the Bazel sandbox,
# which will be deleted automatically after the compiler exits.
(flagfile_fd, flagfile_path) = tempfile.mkstemp(dir='./', suffix=".linker-params")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use a context manager here, i.e. with?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

sanitize_flagfile(arg[len("-Wl,@"):], flagfile_fd)
os.close(flagfile_fd)
argv.append("-Wl,@" + flagfile_path)
else:
argv.append(arg)
else:
argv = sys.argv[1:]
os.execv(compiler, [compiler] + argv)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a pretty cool approach actually. It seems this gives us a lot of freedom to fix Bazel issues that aren't addressed upstream via the wrapper. Neat.


if __name__ == "__main__":
main()
Loading