For easier debugging, this should help in finding the offending binary:

$ Rebuild mesa without "-rtlib=libgcc"

For all binaries installed by mesa:
 $ readelf -sW $binary|grep unwind_cpp|grep UNDEF

Quick Explanation:

For a test binary, __aeabi_unwind_cpp_pr1 symbol is HIDDEN.

   146: 00002c29     4 FUNC    LOCAL  HIDDEN    13 __aeabi_unwind_cpp_pr1

So, the binary causing the problem should have this symbol UNDEFINED.

That didn't seem to work...

===

for binary in $(equery-cheza files mesa | grep 'so$'); do
  echo "------- $binary ---------"
  readelf -sW /build/cheza/$binary|grep unwind_cpp|grep UNDEF
done

------- /usr/lib/dri/kms_swrast_dri.so ---------
------- /usr/lib/dri/swrast_dri.so ---------
------- /usr/lib/libEGL.so ---------
------- /usr/lib/libGLESv2.so ---------
------- /usr/lib/libglapi.so ---------

Thanks Doug, 
I can try taking a look. Is it possible for you to upload the full mesa package tarball somewhere? The package should be /build/cheza/packages/media-libs/mesa*.tbz2

@4: OK, I've shared:

mesa-17.2.3-r17.tbz2 - without "media-libs/mesa: Fix llvmpipe on arm"
mesa-17.2.3-r18.tbz2 - with "media-libs/mesa: Fix llvmpipe on arm"

...so you want r17.

Anyone @google should be able to download them with:

* https://drive.google.com/file/d/1pqcX94scnR35-MmDHfCn3K5lS8j6tPdd/view?usp=sharing
* https://drive.google.com/file/d/1sZZtMP6VCeLVk5H5YcoToKP8ZO-bGN3w/view?usp=sharing

I don't see any unwind related symbols. But I see the following:

$ for binary in $(find usr/ -iname "*.so*") ; do echo $binary; readelf -sW $binary|grep -i unwind; done
usr/lib/dri/swrast_dri.so
    10: 00000000     0 FUNC    WEAK   DEFAULT  UND __gnu_Unwind_Find_exidx@GLIBC_2.4 (2)
usr/lib/dri/kms_swrast_dri.so
    10: 00000000     0 FUNC    WEAK   DEFAULT  UND __gnu_Unwind_Find_exidx@GLIBC_2.4 (2)

According to my understanding (based on Google search), __gnu_Unwind_Find_exidx is used to find the unwinder index table which is not working when static linking is used.

I could be totally wrong here but seems like mesa softpipe build system is assuming a a shared library linkage.

So I think it needs a fix in mesa's softpipe implementation. Assign back to Marcheu@ since I have no clue about mesa softpipe.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/5154ea2b1b52d39ef49181e01359d383139ff22d

commit 5154ea2b1b52d39ef49181e01359d383139ff22d
Author: Manoj Gupta <manojgupta@google.com>
Date: Sun Oct 21 20:37:59 2018

platform_ToolchainOptions: Filter some mesa binaries.

mesa on cheza is currently using libgcc_s.
Filter the mesa binaries till the libgcc_s dependency can be fixed
in mesa.

BUG=b:117628203
BUG=chromium:808264

TEST=platform_ToolchainOptions does not complain about these files.

Change-Id: Idce12e4d5d6a7a72d80cdc53d624c86d3be38816
Reviewed-on: https://chromium-review.googlesource.com/1292278
Commit-Ready: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Luis Lozano <llozano@chromium.org>

[modify] https://crrev.com/5154ea2b1b52d39ef49181e01359d383139ff22d/client/site_tests/platform_ToolchainOptions/libgcc_whitelist