binutils: backport fix for gold with theads enabled from 2.36.0

* building chromium with gold and threads triggers this issue:
  [1/2] SOLINK ./libcbe.so
  FAILED: libcbe.so libcbe.so.TOC
  python "../../git/src/build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="nm" --sofile="./libcbe.so" --tocfile="./libcbe.so.TOC" --output="./libcbe.so" -- i686-oe-linux-g++  -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security  --sysroot=chromium/84.0.4147.89-4-r41.1/recipe-sysroot -shared -Wl,-soname="libcbe.so" -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -fuse-ld=gold -Wl,--threads -Wl,--thread-count=4 -m32 -Wl,-O2 -Wl,--gc-sections -rdynamic --sysroot=../../recipe-sysroot -L../../recipe-sysroot/lib -L../../recipe-sysroot/usr/lib -Lchromium/84.0.4147.89-4-r41.1/recipe-sysroot -o "./libcbe.so" @"./libcbe.so.rsp"
  collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
  compilation terminated.

* removing threads/thread-count is one possible work around, but then
  the use of gold for performance makes even less sense, that's why
  chromium from meta-browser uses LLD by default:
  15228b0190
  https://lld.llvm.org/#performance
  but lets backport this as other recipes might also reproduce this
  issue

(From OE-Core rev: eaf4548a58d1b926b38beab28d75f8710c8b078a)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

meta/recipes-devtools/binutils/binutils-2.35.1.inc

@@ -44,5 +44,6 @@ SRC_URI = "\
      file://0017-gas-improve-reproducibility-for-stabs-debugging-data.patch \
      file://0001-aarch64-Return-an-error-on-conditional-branch-to-an-.patch \
      file://CVE-2020-35448.patch \
+     file://0001-gold-ensure-file_counts_lock-is-initialized-before-u.patch \
 "
 S  = "${WORKDIR}/git"

meta/recipes-devtools/binutils/binutils/0001-gold-ensure-file_counts_lock-is-initialized-before-u.patch

@@ -0,0 +1,41 @@
+From de24fc96bf24fca470a9ca13176ad9ad9cc4d5a9 Mon Sep 17 00:00:00 2001
+From: Nick Gasson <nick.gasson@arm.com>
+Date: Mon, 2 Nov 2020 12:02:05 +0800
+Subject: [PATCH] gold: ensure file_counts_lock is initialized before using
+
+Since upgrading to binutils 2.35 I've been experiencing random memory
+corruption related crashes with ld.gold --threads. It's caused by
+multiple threads concurrently pushing elements onto the shared
+std::vector in File_read::record_file_read(). This vector is supposed to
+be protected by file_counts_lock, but that is initialized lazily and
+might be NULL when File_read::open() is called, in which case
+Hold_optional_lock silently skips locking it.
+
+Fix by calling the initialize() method before attempting to acquire the
+lock, the same as other places that use file_counts_lock.
+
+	PR 26827
+	* fileread.cc (File_read::open): Ensure file_counts_lock is
+	initialized.
+	* testsuite/Makefile.am (check_PROGRAMS): Add a test that passes
+	-Wl,--threads.
+	* testsuite/Makefile.in: Regenerate.
+
+Upstream-Status: Backport [af61e84fd2d from 2.36.0]
+Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
+---
+ gold/fileread.cc | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/gold/fileread.cc b/gold/fileread.cc
+index f5ca719360d..0b5228e2afd 100644
+--- a/gold/fileread.cc
++++ b/gold/fileread.cc
+@@ -212,6 +212,7 @@ File_read::open(const Task* task, const std::string& name)
+       gold_debug(DEBUG_FILES, "Attempt to open %s succeeded",
+ 		 this->name_.c_str());
+       this->token_.add_writer(task);
++      file_counts_initialize_lock.initialize();
+       Hold_optional_lock hl(file_counts_lock);
+       record_file_read(this->name_);
+     }