diff mbox series

[committed] libstdc++: Fix symbol versioning for Solaris 11.3 [PR103407]

Message ID 20220316212453.243636-1-jwakely@redhat.com
State New
Headers show
Series [committed] libstdc++: Fix symbol versioning for Solaris 11.3 [PR103407] | expand

Commit Message

Jonathan Wakely March 16, 2022, 9:24 p.m. UTC 
Tested x86_64-linux and sparc-sun-solaris2.11 (but 11.3 only).

Pushed to trunk.

Rainer, this should allow you to continue omitting the
_ZSt10from_charsPKcS0_R[def]St12chars_format symbols from the baseline,
without the current FAIL. Please check on your other Solaris targets.

-- >8 --

The new std::from_chars implementation means that those symbols are now
defined on Solaris 11.3, which lacks uselocale. They were not present in
gcc-11, but the linker script gives them the GLIBCXX_3.4.29 symbol
version because that is the version where they appeared for systems with
uselocale.

This makes the version for those symbols depend on whether uselocale is
available or not, so that they get version GLIBCXX_3.4.30 on targets
where they weren't defined in gcc-11.

In order to avoid needing separate ABI baseline files for Solaris 11.3
and 11.4, the ABI checker program now treats the floating-point
std::from_chars overloads as undesignated if they are not found in the
baseline symbols file. This means they can be left out of the SOlaris
baseline without causing the check-abi target to fail.

libstdc++-v3/ChangeLog:

	PR libstdc++/103407
	* config/abi/pre/gnu.ver: Make version for std::from_chars
	depend on HAVE_USELOCALE macro.
	* testsuite/util/testsuite_abi.cc (compare_symbols): Treat
	std::from_chars for floating-point types as undesignated if
	not found in the baseline symbols file.
---
 libstdc++-v3/config/abi/pre/gnu.ver          |  7 +++++++
 libstdc++-v3/testsuite/util/testsuite_abi.cc | 13 +++++++++++++
 2 files changed, 20 insertions(+)

Comments

Rainer Orth March 18, 2022, 11:49 a.m. UTC | #1 
Hi Jonathan,

> Tested x86_64-linux and sparc-sun-solaris2.11 (but 11.3 only).
>
> Pushed to trunk.
>
> Rainer, this should allow you to continue omitting the
> _ZSt10from_charsPKcS0_R[def]St12chars_format symbols from the baseline,
> without the current FAIL. Please check on your other Solaris targets.

I've run bootstraps on i386-pc-solaris2.11 (Solaris 11.3 and 11.4) and
sparc-sun-solaris2.11 (Solaris 11.4) last night: the abi_check failures
are gone everywhere.

Thanks a lot for your patience with this issue.

	Rainer
Jonathan Wakely March 18, 2022, 12:21 p.m. UTC | #2 
On Fri, 18 Mar 2022 at 11:49, Rainer Orth wrote:
>
> Hi Jonathan,
>
> > Tested x86_64-linux and sparc-sun-solaris2.11 (but 11.3 only).
> >
> > Pushed to trunk.
> >
> > Rainer, this should allow you to continue omitting the
> > _ZSt10from_charsPKcS0_R[def]St12chars_format symbols from the baseline,
> > without the current FAIL. Please check on your other Solaris targets.
>
> I've run bootstraps on i386-pc-solaris2.11 (Solaris 11.3 and 11.4) and
> sparc-sun-solaris2.11 (Solaris 11.4) last night: the abi_check failures
> are gone everywhere.

Hooray!

I did some very brief testing and it seemed like a program linked to
the Solaris 11.3 libstdc++.so.6.0.30 (with from_chars@GLIBCXX_3.4.30)
can still run against libstdc++.so.6.0.30 with
from_chars@GLIBCXX_3.4.29 (which should match what you get on Solaris
11.4 if I correctly fiddled with the versioning). So I don't
understand how the Solaris runtime linker handles symbol versions, but
it seems like there's no backwards compatibility problem for the
Solaris 11.4 build of libstdc++.so.6.0.30.
Rainer Orth March 18, 2022, 12:47 p.m. UTC | #3 
Hi Jonathan,

> I did some very brief testing and it seemed like a program linked to
> the Solaris 11.3 libstdc++.so.6.0.30 (with from_chars@GLIBCXX_3.4.30)
> can still run against libstdc++.so.6.0.30 with
> from_chars@GLIBCXX_3.4.29 (which should match what you get on Solaris
> 11.4 if I correctly fiddled with the versioning). So I don't

indeed.  You can observe the symbols provided and consumed by shared
objects and executables with pvs.

E.g. on 11.4:

$ pvs -dsvo libstdc++.so|grep _ZSt10from_charsPKcS0_R
libstdc++.so -	GLIBCXX_3.4.29: _ZSt10from_charsPKcS0_RfSt12chars_format;
libstdc++.so -	GLIBCXX_3.4.29: _ZSt10from_charsPKcS0_ReSt12chars_format;
libstdc++.so -	GLIBCXX_3.4.29: _ZSt10from_charsPKcS0_RdSt12chars_format;

for the provider side vs. 11.3:

$ pvs -dsvo libstdc++.so|grep _ZSt10from_charsPKcS0_R
libstdc++.so -	GLIBCXX_3.4.30: _ZSt10from_charsPKcS0_ReSt12chars_format;
libstdc++.so -	GLIBCXX_3.4.30: _ZSt10from_charsPKcS0_RdSt12chars_format;
libstdc++.so -	GLIBCXX_3.4.30: _ZSt10from_charsPKcS0_RfSt12chars_format;

pvs -r shows symbols and versions required by an executable.

> understand how the Solaris runtime linker handles symbol versions, but
> it seems like there's no backwards compatibility problem for the
> Solaris 11.4 build of libstdc++.so.6.0.30.

You can observe this at runtime with LD_DEBUG=versions or
versions,detail.  LD_DEBUG=help <some command> gives the full info.

IIRC Solaris ld.so.1 just checks if the versions required by an
executable are provided by a shared object, but doesn't look into
individual symbols in advance.  It may well be that some checks have
been relaxed in the 11.4 timeframe, though.

	Rainer
Jonathan Wakely March 18, 2022, 12:51 p.m. UTC | #4 
On Fri, 18 Mar 2022 at 12:47, Rainer Orth wrote:
>
> Hi Jonathan,
>
> > I did some very brief testing and it seemed like a program linked to
> > the Solaris 11.3 libstdc++.so.6.0.30 (with from_chars@GLIBCXX_3.4.30)
> > can still run against libstdc++.so.6.0.30 with
> > from_chars@GLIBCXX_3.4.29 (which should match what you get on Solaris
> > 11.4 if I correctly fiddled with the versioning). So I don't
>
> indeed.  You can observe the symbols provided and consumed by shared
> objects and executables with pvs.
>
> E.g. on 11.4:
>
> $ pvs -dsvo libstdc++.so|grep _ZSt10from_charsPKcS0_R
> libstdc++.so -  GLIBCXX_3.4.29: _ZSt10from_charsPKcS0_RfSt12chars_format;
> libstdc++.so -  GLIBCXX_3.4.29: _ZSt10from_charsPKcS0_ReSt12chars_format;
> libstdc++.so -  GLIBCXX_3.4.29: _ZSt10from_charsPKcS0_RdSt12chars_format;
>
> for the provider side vs. 11.3:
>
> $ pvs -dsvo libstdc++.so|grep _ZSt10from_charsPKcS0_R
> libstdc++.so -  GLIBCXX_3.4.30: _ZSt10from_charsPKcS0_ReSt12chars_format;
> libstdc++.so -  GLIBCXX_3.4.30: _ZSt10from_charsPKcS0_RdSt12chars_format;
> libstdc++.so -  GLIBCXX_3.4.30: _ZSt10from_charsPKcS0_RfSt12chars_format;
>
> pvs -r shows symbols and versions required by an executable.
>
> > understand how the Solaris runtime linker handles symbol versions, but
> > it seems like there's no backwards compatibility problem for the
> > Solaris 11.4 build of libstdc++.so.6.0.30.
>
> You can observe this at runtime with LD_DEBUG=versions or
> versions,detail.  LD_DEBUG=help <some command> gives the full info.
>
> IIRC Solaris ld.so.1 just checks if the versions required by an
> executable are provided by a shared object, but doesn't look into
> individual symbols in advance.  It may well be that some checks have
> been relaxed in the 11.4 timeframe, though.

Ah that would explain it. The libstdc++.so built on Solaris 11.4 has
the std::from_chars symbols and it has version GLIBCXX_3.4.30, so that
satisfies the requirements for a program linked against the
libstdc++.so on Solaris 11.3.
diff mbox series

Patch

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index dedee8c1b0a..9b80a31768b 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2337,8 +2337,10 @@  GLIBCXX_3.4.28 {
 
 GLIBCXX_3.4.29 {
 
+#ifdef HAVE_USELOCALE
     # std::from_chars
     _ZSt10from_charsPKcS0_R[def]St12chars_format;
+#endif
 
     # std::__istream_extract(istream&, char*, streamsize)
     _ZSt17__istream_extractRSiPc[ilx];
@@ -2416,6 +2418,11 @@  GLIBCXX_3.4.29 {
 
 GLIBCXX_3.4.30 {
 
+#ifndef HAVE_USELOCALE
+    # std::from_chars
+    _ZSt10from_charsPKcS0_R[def]St12chars_format;
+#endif
+
     _ZSt21__glibcxx_assert_fail*;
 
 #ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
diff --git a/libstdc++-v3/testsuite/util/testsuite_abi.cc b/libstdc++-v3/testsuite/util/testsuite_abi.cc
index 3dee737b2e5..5c8383554e5 100644
--- a/libstdc++-v3/testsuite/util/testsuite_abi.cc
+++ b/libstdc++-v3/testsuite/util/testsuite_abi.cc
@@ -499,6 +499,19 @@  compare_symbols(const char* baseline_file, const char* test_file,
 	  else
 	    undesignated.push_back(stest);
 	}
+      // See PR libstdc++/103407 -  abi_check FAILs on Solaris
+      else if (stest.type == symbol::function
+		 && stest.name.compare(0, 23, "_ZSt10from_charsPKcS0_R") == 0
+		 && stest.name.find_first_of("def", 23) == 23
+		 && (stest.version_name == "GLIBCXX_3.4.29"
+		       || stest.version_name == "GLIBCXX_3.4.30"))
+	{
+	  stest.status = symbol::undesignated;
+	  if (!check_version(stest, false))
+	    incompatible.push_back(symbol_pair(stest, stest));
+	  else
+	    undesignated.push_back(stest);
+	}
       else
 	{
 	  stest.status = symbol::added;