It looks like blimp is the only client of grpc.

We probably need either https://cs.chromium.org/chromium/src/third_party/grpc/binding.gyp?q=wrap,memcpy&sq=package:chromium&l=807&dr=C in the gn build as well, or we need to remove https://cs.chromium.org/chromium/src/third_party/grpc/src/core/lib/support/wrap_memcpy.c?q=wrap_memcpy&sq=package:chromium&dr=CSs from the build.

This makes things go:

~/src/chrome/src/third_party/grpc$ git diff
diff --git a/BUILD.gn b/BUILD.gn
index 4490add..88f76ae 100644
--- a/BUILD.gn
+++ b/BUILD.gn
@@ -27,6 +27,7 @@ config("grpc_config") {
   cflags_c = [
     "-std=c99"
   ]
+  ldflags = [ "-Wl,-wrap,memcpy" ]
   
   if (is_android) {
     libs = [ "log" ] # For __android_log_write


But maybe not including wrap_memcpy.cc in the build is better. xyzzyz, giving this to you, you probably have a better idea what exactly to do here.  This blocks moving chrome/android/x64 to clang by default, so please take a look.


cc primiano since it interacts a bit with https://cs.chromium.org/chromium/src/base/allocator/BUILD.gn?dr=C&q=wrap,memalign&sq=package:chromium&l=294

actually cc primiano

Right now we don't have any wrapping and everything works. Would be great to avoid wrapping memcpy unless we really really have to.
The thing that is not clear to me right now is: how come that code doesn't fail on gcc? Maybe Android's gcc just drops the @GLIBC_2.2.5 versioning on the floor?
Happy to help, trying to build right now.

Ahh I see what's happening. GCC ends up optimizing the memcpy call with a builtin which drops any dynamic symbol requirement. clang does not.

$ objdump -d out/x64_clang/obj/third_party/grpc/gpr/wrap_memcpy.o
0000000000000000 <__wrap_memcpy>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   53                      push   %rbx
   5:   50                      push   %rax
   6:   48 89 fb                mov    %rdi,%rbx
   9:   e8 00 00 00 00          callq  e <__wrap_memcpy+0xe>
   e:   48 89 d8                mov    %rbx,%rax
  11:   48 83 c4 08             add    $0x8,%rsp
  15:   5b                      pop    %rbx
  16:   5d                      pop    %rbp
  17:   c3                      retq
$ nm out/x64_clang/obj/third_party/grpc/gpr/wrap_memcpy.o
0000000000000000 T __wrap_memcpy
                 U memcpy@GLIBC_2.2.5


$ objdump -d out/x64_gcc/obj/third_party/grpc/gpr/wrap_memcpy.o
0000000000000000 <__wrap_memcpy>:
   0:   55                      push   %rbp
   1:   48 89 f8                mov    %rdi,%rax
   4:   48 89 d1                mov    %rdx,%rcx
   7:   f3 a4                   rep movsb %ds:(%rsi),%es:(%rdi)
   9:   48 89 e5                mov    %rsp,%rbp
   c:   5d                      pop    %rbp
   d:   c3                      retq

$ nm out/x64_gcc/obj/third_party/grpc/gpr/wrap_memcpy.o
0000000000000000 T __wrap_memcpy

So, because of this, it looks to me that:
- that grpc code is unaware of Android and should be fixed upstream.
- so far we were practically ignorning that piece of code. I chatted a bit offline with thakis@. the best thing is to just exclude memcpy.c from the GN build file.

Forgot to say that this is very likely the last thing keeping compile on https://build.chromium.org/p/chromium.fyi/builders/ClangToTAndroid%20x64 red

Ehm changing that BUILD.gn seems quite complicated.
The BUILD.gn is part of the third_party/grpc project. The file itself is autogenerated from a templates/BUILD.gn.template

I was trying to just get this:
-----
index 4490add..eb489d0 100644
--- a/BUILD.gn
+++ b/BUILD.gn
@@ -139,6 +139,11 @@ source_set("gpr") {
     "src/core/lib/support/tmpfile_windows.c",
     "src/core/lib/support/wrap_memcpy.c",
   ]
+  if (is_android) {
+    # gRPC memcpy wrapping logic isn't Android-friendly.
+    # See  https://crbug.com/661171  .
+    sources -= [ "src/core/lib/support/wrap_memcpy.c" ]
+  }
   deps = [
   ]
   configs -= [ "//build/config/compiler:chromium_code" ]
-----

But looks not that trivial. can somebody familiar with that workflow do that? I confirm that the target compiles with that change, both with gcc and clang.

Sure, I'll get to this in a few minutes.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fbad888c3366b08ff3b8253b0c3b52e440015d50

commit fbad888c3366b08ff3b8253b0c3b52e440015d50
Author: gcasto <gcasto@chromium.org>
Date: Tue Nov 01 21:16:31 2016

Rolls DEPS for gRPC to fix an Android and Clang compilation error

BUG= 661171 

Review-Url: https://codereview.chromium.org/2472513002
Cr-Commit-Position: refs/heads/master@{#429113}

[modify] https://crrev.com/fbad888c3366b08ff3b8253b0c3b52e440015d50/DEPS

Should be fixed now. gRPC repo change was https://codereview.chromium.org/2471543002/.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ff8a991d4cbccf1c9eb893d3e7a310767fd18058

commit ff8a991d4cbccf1c9eb893d3e7a310767fd18058
Author: tzik <tzik@chromium.org>
Date: Fri Dec 09 09:48:07 2016

Roll gRPC for LLD link fix

BUG= 661171 

Review-Url: https://codereview.chromium.org/2561753002
Cr-Commit-Position: refs/heads/master@{#437507}

[modify] https://crrev.com/ff8a991d4cbccf1c9eb893d3e7a310767fd18058/DEPS

That last roll commit picked up https://codereview.chromium.org/2554783002