More context here.
I created two nacl_helper binary with gold and lld using the same commandline. The only difference is -fuse-ld=gold and -fuse-ld=lld.
The output of ldd nacl_helper is as follows.

The ldd one missed several libraries because -Wl,as-needed was in the command line and lld thinks there is no symbol being used from these libraries and there is no linkage to these libraries.

There was an upstream bug https://bugs.llvm.org/show_bug.cgi?id=28335
But that fix does not fix this issue.

gold:
	linux-vdso.so.1 (0x00007fff7d7fd000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc8d38f4000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc8d36d8000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fc8d34d0000)
	libnss3.so => /usr/lib64/libnss3.so (0x00007fc8d3bf8000)
	libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007fc8d3bcc000)
	libnspr4.so => /usr/lib64/libnspr4.so (0x00007fc8d3292000)
	libdrm.so.2 => not found
	libsync.so => not found
	libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fc8d3051000)
	libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007fc8d2e02000)
	libxkbcommon.so.0 => not found
	libm.so.6 => /lib64/libm.so.6 (0x00007fc8d2afb000)
	libgestures.so.0 => not found
	libevdev.so => not found
	libasound.so.2 => /usr/lib64/libasound.so.2 (0x00007fc8d281f000)
	libcras.so.0 => not found
	libgbm.so.1 => not found
	libc++.so.1 => /usr/lib64/libc++.so.1 (0x00007fc8d255a000)
	libc++abi.so.1 => /usr/lib64/libc++abi.so.1 (0x00007fc8d2323000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.x/libgcc_s.so.1 (0x00007fc8d210c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc8d1d65000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc8d3af8000)
	libplc4.so => /usr/lib64/libplc4.so (0x00007fc8d1b60000)
	libplds4.so => /usr/lib64/libplds4.so (0x00007fc8d195c000)
	libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fc8d16b2000)
	libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fc8d1487000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fc8d126e000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fc8d105a000)
	libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fc8d0e22000)


ldd
        linux-vdso.so.1 (0x00007ffd0354e000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc158ac6000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc1588aa000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fc1586a2000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fc15839b000)
	libc++.so.1 => /usr/lib64/libc++.so.1 (0x00007fc1580d6000)
	libc++abi.so.1 => /usr/lib64/libc++abi.so.1 (0x00007fc157e9f000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc157af8000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc158cca000)

As per https://reviews.llvm.org/D45536, Rui's change was reverted because it broke Chromium. Can you check if he made another fix?

Please also attach output of -Wl,-t and check where are the builtins coming from.

This is important because we want builtins to come from libgcc, not any other library that might be carrying the compiler-rt implementation (We had an issue with clear_cache compiler-rt builtin on ARM).

https://reviews.llvm.org/rL330788 relanded that patch and we have that already.

By the way, the error is rather misleading because NaCl does not use pthread_cancel().  The error arises because glibc's libpthread has some dependency on stack unwinding functions from libgcc_s.so such as _Unwind_Resume().  Note that NaCl does not use stack unwinding either.  Some C++ libraries depend on stack unwinding for C++ exception handling, which we also don't use.

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

commit 17a40397711ee604334d86f9533f1ea1cc327c3f
Author: Yunlian Jiang <yunlian@google.com>
Date: Fri Sep 21 16:09:26 2018

nacl_helper: force to link with lgcc_s on ChromeOS.

When linking with lld, the lgcc_s is removed from linkage and this
makes Nacl failed to load. This cl adds -lgcc_s before --as-needed
so that libgcc_s is kept.

BUG= chromium:884017 
TEST=nacl_helper works when linking with lld.

Change-Id: I3a8503787c4b05b7f777c82bc279ae1005d604d1
Reviewed-on: https://chromium-review.googlesource.com/1226452
Commit-Queue: Yunlian Jiang <yunlian@chromium.org>
Reviewed-by: Mark Seaborn <mseaborn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593207}
[modify] https://crrev.com/17a40397711ee604334d86f9533f1ea1cc327c3f/components/nacl/loader/BUILD.gn

I suspect what is happening here is the following:

 * Something triggers a stack unwind, either in Chromium or a system library, maybe by throwing a C++ exception.

 * There is a function on the call stack that uses __attribute__((cleanup)), which in turn uses __gcc_personality_v0() as its personality function (for doing cleanup when an exception is thrown).  This is probably a function in glibc (libc or libpthread).

 * This calls the copy of __gcc_personality_v0() defined in glibc.  (See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/gnu/unwind-resume.c;h=9283d925decb31f6cccbdde5fa117bcb5b983910;hb=f0458cf4f9ff3d870c43b624e6dccaaf657d5e83)

 * This tries to redirect to the real implementation of __gcc_personality_v0() in libgcc_s.so.  It tries to dlopen() that library.  The library wasn't loaded at startup, so the dynamic linker tries to open() it from the filesystem.  But Chrome's sandbox is enabled at this point, and so opening the library fails, producing the error message in the issue report.

In newer versions of glibc, the error message has been changed to "libgcc_s.so.1 must be installed for unwinding to work" (see https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=08c6e95234c60a5c2f37532d1111acf084f39345;hp=d8b778907e5270fdeb70459842ffbc20bd2ca5e1).