All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Mazovetskiy <glex.spb@gmail.com>
To: buildroot@buildroot.org
Cc: Gleb Mazovetskiy <glex.spb@gmail.com>,
	Romain Naour <romain.naour@gmail.com>,
	Giulio Benetti <giulio.benetti@benettiengineering.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: [Buildroot] [PATCH] package/gcc: fix gcc12 with uClibc
Date: Fri, 23 Dec 2022 17:49:21 +0000	[thread overview]
Message-ID: <20221223174922.12131-1-glex.spb@gmail.com> (raw)

GCC 12 produces broken binaries when used with uClibc.
E.g. `gdb` crashes on startup.

GCC HEAD fixes this in:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=ee4af2ed0b7322884ec4ff537564683c3749b813

Adds the commit as patch for GCC 12.

Signed-off-by: Gleb Mazovetskiy <glex.spb@gmail.com>
---
 package/gcc/12.2.0/0002-fix-condvar.patch | 80 +++++++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 package/gcc/12.2.0/0002-fix-condvar.patch

diff --git a/package/gcc/12.2.0/0002-fix-condvar.patch b/package/gcc/12.2.0/0002-fix-condvar.patch
new file mode 100644
index 0000000000..b5575e5df2
--- /dev/null
+++ b/package/gcc/12.2.0/0002-fix-condvar.patch
@@ -0,0 +1,80 @@
+From ee4af2ed0b7322884ec4ff537564683c3749b813 Mon Sep 17 00:00:00 2001
+From: Jonathan Wakely <jwakely@redhat.com>
+Date: Thu, 22 Dec 2022 09:56:47 +0000
+Subject: [PATCH] libstdc++: Avoid recursion in __nothrow_wait_cv::wait
+ [PR105730]
+
+The commit r12-5877-g9e18a25331fa25 removed the incorrect
+noexcept-specifier from std::condition_variable::wait and gave the new
+symbol version @@GLIBCXX_3.4.30. It also redefined the original symbol
+std::condition_variable::wait(unique_lock<mutex>&)@GLIBCXX_3.4.11 as an
+alias for a new symbol, __gnu_cxx::__nothrow_wait_cv::wait, which still
+has the incorrect noexcept guarantee. That __nothrow_wait_cv::wait is
+just a wrapper around the real condition_variable::wait which adds
+noexcept and so terminates on a __forced_unwind exception.
+
+This doesn't work on uclibc, possibly due to a dynamic linker bug. When
+__nothrow_wait_cv::wait calls the condition_variable::wait function it
+binds to the alias symbol, which means it just calls itself recursively
+until the stack overflows.
+
+This change avoids the possibility of a recursive call by changing the
+__nothrow_wait_cv::wait function so that instead of calling
+condition_variable::wait it re-implements it. This requires accessing
+the private _M_cond member of condition_variable, so we need to use the
+trick of instantiating a template with the member-pointer of the private
+member.
+
+libstdc++-v3/ChangeLog:
+
+	PR libstdc++/105730
+	* src/c++11/compatibility-condvar.cc (__nothrow_wait_cv::wait):
+	Access private data member of base class and call its wait
+	member.
+---
+ .../src/c++11/compatibility-condvar.cc        | 22 ++++++++++++++++++-
+ 1 file changed, 21 insertions(+), 1 deletion(-)
+
+diff --git a/libstdc++-v3/src/c++11/compatibility-condvar.cc b/libstdc++-v3/src/c++11/compatibility-condvar.cc
+index e3a8b8403ca..3cef3bc0714 100644
+--- a/libstdc++-v3/src/c++11/compatibility-condvar.cc
++++ b/libstdc++-v3/src/c++11/compatibility-condvar.cc
+@@ -67,6 +67,24 @@ _GLIBCXX_END_NAMESPACE_VERSION
+     && defined(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT)
+ namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
+ {
++namespace
++{
++  // Pointer-to-member for private std::condition_variable::_M_cond member.
++  std::__condvar std::condition_variable::* __base_member;
++
++  template<std::__condvar std::condition_variable::*X>
++    struct cracker
++    { static std::__condvar std::condition_variable::* value; };
++
++  // Initializer for this static member also initializes __base_member.
++  template<std::__condvar std::condition_variable::*X>
++    std::__condvar std::condition_variable::*
++      cracker<X>::value = __base_member = X;
++
++  // Explicit instantiation is allowed to access the private member.
++  template class cracker<&std::condition_variable::_M_cond>;
++}
++
+ struct __nothrow_wait_cv : std::condition_variable
+ {
+   void wait(std::unique_lock<std::mutex>&) noexcept;
+@@ -76,7 +94,9 @@ __attribute__((used))
+ void
+ __nothrow_wait_cv::wait(std::unique_lock<std::mutex>& lock) noexcept
+ {
+-  this->condition_variable::wait(lock);
++  // In theory this could be simply this->std::condition_variable::wait(lock)
++  // but with uclibc that binds to the @GLIBCXX_3.4.11 symbol, see PR 105730.
++  (this->*__base_member).wait(*lock.mutex());
+ }
+ } // namespace __gnu_cxx
+ 
+-- 
+2.31.1
+
-- 
2.37.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

             reply	other threads:[~2022-12-23 17:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-23 17:49 Gleb Mazovetskiy [this message]
2022-12-27 21:27 ` [Buildroot] [PATCH] package/gcc: fix gcc12 with uClibc Thomas Petazzoni via buildroot
2023-01-02 12:06 ` Peter Korsgaard
     [not found] <mailman.11703.1671657429.89793.buildroot@buildroot.org>
2022-12-22 10:49 ` Andreas Ziegler
  -- strict thread matches above, loose matches on Subject: below --
2022-12-21 20:03 Gleb Mazovetskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221223174922.12131-1-glex.spb@gmail.com \
    --to=glex.spb@gmail.com \
    --cc=buildroot@buildroot.org \
    --cc=giulio.benetti@benettiengineering.com \
    --cc=romain.naour@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.