Sounds like we're either missing a -B flag, or clang doesn't use that for objcopy when doing fission.

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

commit adfc38c0c88649db43452498516e1dd6fbf91ec3
Author: Bernhard Bauer <bauerb@chromium.org>
Date: Fri May 12 18:08:39 2017

Disable debug_fission by default for Android builds

Before https://crrev.com/471243, it was implicitly disabled on Android
due to |linux_use_bundled_binutils| being false. The removal of that
check broke Android builds with symbol_level=2.

BUG= 721792 

Change-Id: I13bb41f994a8eaf35519df53cf0410612b18d7d1
Reviewed-on: https://chromium-review.googlesource.com/504507
Commit-Queue: Bernhard Bauer <bauerb@chromium.org>
Reviewed-by: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Nicolas Dossou-Gbété <dgn@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#471368}
[modify] https://crrev.com/adfc38c0c88649db43452498516e1dd6fbf91ec3/build/config/compiler/BUILD.gn

I continue to see the same errors with only the following gn args

target_os = "android"                                                           
is_clang = true 

But reverting the cited CL does fix the issue.

Given that I could reproduce in a pretty default config, I've also bumped the priority.

Huh, it works for me with those exact args. Can you attach the output of `gn args <out dir> --list`?

I ran into this issue on Friday too. The patch in #2 fixes it for me but the Clank repro hadn't rolled it yet so I had to apply it manually. It looks like it's been rolled in now.

Back to p3 then :-)

A clean fetch and sync worked for me today.

Same issue is present when cross-compiling Chromium Linux in debug mode for mipsel.

gn args:

is_debug=true 
target_os="linux" 
target_cpu="mipsel" 
mips_arch_variant="r2"

/usr/bin/objcopy is used and it complains:

/usr/bin/objcopy: Unable to recognise the format of the input file `obj/base/base_static/switches.o'

With added linux_use_bundled_binutils=true to gn args, //third_party/binutils/Linux_x64/Release/bin/objcopy is used but it also reports the same error, since it does not support mipsel.

./third_party/binutils/Linux_x64/Release/bin/objcopy --help
...
./third_party/binutils/Linux_x64/Release/bin/objcopy: supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 a.out-i386-linux pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big plugin srec symbolsrec verilog tekhex binary ihex

I gave this a shot with this diff:

thakis@thakis:~/src/chrome/src$ git diff
diff --git a/build/config/compiler/BUILD.gn b/build/config/compiler/BUILD.gn
index efbf047f6168..88147376dcf3 100644
--- a/build/config/compiler/BUILD.gn
+++ b/build/config/compiler/BUILD.gn
@@ -1723,6 +1723,12 @@ config("symbols") {
     }
     if (use_debug_fission) {
       cflags += [ "-gsplit-dwarf" ]
+      if (is_android && current_toolchain != host_toolchain) {
+        # Let the compiler find the right objcopy, for fission.
+        objcopy_path = rebase_path("$android_toolchain_root/bin",
+                                   root_build_dir)
+        cflags += [ "-B$objcopy_path" ]
+      }
     }
     asmflags = cflags
     ldflags = []

With that all the

/usr/bin/objcopy: Unable to recognise the format of the input file `obj/gpu/command_buffer/client/gles2_implementation/gles2_implementation.o'

printed during the build went away, but the build felt very slow. Turns out that now all compiles failed on goma, with stderr

/work/14765896817282439595/compiler/gtrusty_gold/bin/objcopy: Unable to recognise the format of the input file `obj/cc/paint/paint/paint_flags.o'

ukai, has your team thought about supporting fission in cross builds? It'd be cool if we could get that to work eventually.

hmm, failed to detect objcopy's path/hash, so backend tried to use default one?

anyway, if

/usr/bin/objcopy: Unable to recognise the format of the input file `obj/gpu/command_buffer/client/gles2_implementation/gles2_implementation.o'

printed during the build went away, local compile also didn't use correct objcopy , did it? (expected to use $android_toolchain_root/bin/objcopy, not /usr/bin/objcopy?)  so, the configuration is not correct to use cross objcopy?

Local compilation used /use/bin/objcopy before my diff and the android SDK one after. Which is why that error was printed before my diff, but not after.

ah, this patch fixed the local build, but goma failed to recognize the objcopy in the path? 

hmm, maybe compiler_proxy only recognizes "objcopy", but should check "*-*-*-objcopy" ?
https://chrome-internal.googlesource.com/goma/client/+/master/client/compiler_info.cc#98

filed: http://b/63082235

Gentle ping.

According to the issue shown in #16, the fixed goma client has already been released.

Do you still see this issue?