Hmmm; the minimal repro case is using the GCC-cross 'ld' command, which may not know how to add the necessary veneer for the far call?

+mcgrathr: Do you know if there's some magic we're missing here? FWIW linker command-line for our content_unittests binary looks like:

clang++ -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--no-as-needed -lpthread -Wl,--as-needed -fuse-ld=lld -Wl,--icf=all --target=aarch64-fuchsia -resource-dir ../../third_party/fuchsia-sdk/toolchain_libs/clang/6.0.0 -Wl,-z,stack-size=0x800000 -Wl,--no-as-needed -lfdio -Wl,--as-needed -Werror -Wl,--gdb-index -nostdlib++ --sysroot=../../third_party/fuchsia-sdk/sysroot/aarch64-fuchsia -o "./content_unittests" -Wl,--start-group @"./content_unittests.rsp"  -Wl,--end-group   -lzircon -llaunchpad -lmedia_client 

LLD doesn't support inserting veneers at the moment. There's a patch to add that support https://reviews.llvm.org/D34691 but it's still in review.

The code segment is too big for a single BL (call) instruction.
It can address +/- 128MB, so your binary must be pretty darn big.
Should it really be that big?

Re #4: Quite possibly, yes; this is the content_unittests target of Chromium, which builds-in all the unit-tests for the core of the multi-process browser, including the Blink rendering engine and various other large dependencies.  We're (currently) building it statically-linked (versus componentized), and in Debug mode which will mean additional checks, logging and data-structures being built-in.

We may be able to get the Fuchsia component build working again, as a work-around but it has bit-rotted, so if the toolchain fix will arrive soon, perhaps we can avoid that extra work for now.

Looking into the question of whether a 128MB+ text segment is reasonable, I checked the stripped content_unittests size on Linux/x64 and Fuchsia/x64; the *component* build for Linux/x64 is already 60MB (stripped), while the (static) Fuchsia/x64 build is 309MB, FWIW.

Release with DCHECKs is probably better anyway:

is_debug = false
dcheck_always_on = true
is_component_build = false
target_os = "fuchsia"
use_goma = true
symbol_level = 1
target_cpu = "arm64"

I think this is a more useful set of args than a real "debug" or component debug, as we don't have a debugger in any case. It's also what the bots build.

This links content_unittests fine for me (with https://chromium-review.googlesource.com/c/chromium/src/+/722262), I guess because it's smaller. (?) It's still 723M on disk, but the .text is "only" 77.6M.

Seems likely that aarch64 code will be larger than x86_64 code (perhaps by a lot).  So content_unittests really will be very very large.  (A vaguely close comparison might be content_unittests in the aarch64 Android build if that's handy.)

+pcc who's been using https://reviews.llvm.org/D34691 and friends locally for android builds.

+ruiu. FYI, fuchsia builds also need the arm patch series.

Note https://reviews.llvm.org/D34691 addresses the analogous issue for ARM32, but AFAIK nobody has done the work for AArch64, which is what we're talking about here.

Looks like Peter Smith has a patch out for this.
https://reviews.llvm.org/D39744

The change has landed upstream, so a toolchain built after r319307 should have it.  We haven't yet rolled the Fuchsia toolchain up that far and tested this ourselves, but we'll do that soon.

We've verified the new lld works for large binaries on aarch64-fuchsia (i.e., produces binaries that work when run on Fuchsia).
It's in the Fuchsia prebuilt toolchain now.
Chrome folks need to do a Clang roll on their side to pick up recent upstream.

The roll is in, but I'll let you confirm and close the bug.

Confirmed that we can build Debug/Fuchsia/ARM64/static content_unittests successfully, with the latest toolchain.  Thanks!