| Message ID | 20110321091546.GU30899@tyan-ft48-01.lab.bos.redhat.com |
|---|---|
| State | New |
| Headers | show |
> The problem is that abicheck only flags as incompatible additions to > GLIBCXX_3.4, but not other base versions. Ideally it would flag addition > to any version that hasn't been added (addition of the version is flagged > by > OBJECT:0:CXXABI_1.3.5 > etc. entries (no @s in it). > This patch for now just complains about additions to any base versions, > I'll leave the better alternative to you ;) Yes, this seems like an improvement, thanks. I see that I already have a note in testsuite_abi.cc about stricter version checking. -benjamin
On Mon, Mar 21, 2011 at 05:52:52PM +0100, Benjamin Kosnik wrote: > > The problem is that abicheck only flags as incompatible additions to > > GLIBCXX_3.4, but not other base versions. Ideally it would flag addition > > to any version that hasn't been added (addition of the version is flagged > > by > > OBJECT:0:CXXABI_1.3.5 > > etc. entries (no @s in it). > > This patch for now just complains about additions to any base versions, > > I'll leave the better alternative to you ;) > > Yes, this seems like an improvement, thanks. I see that I already have > a note in testsuite_abi.cc about stricter version checking. Well, such stricter checking wouldn't be completely painless, e.g. currently both current baseline_symbols.txt and the ones I've posted don't include the two TLS: lines, because of the fear that not everyone has TLS enabled. If baseline_symbols.txt right now miss some symbols, it is not a big deal if it is not in the base version (with my patch base versions), but with stricter checking it would complain. Either we'd just say that TLS is assumed on these targets and add the TLS: lines, or we'd need to invent some symbol conditionalizing or something. Jakub
> Well, such stricter checking wouldn't be completely painless, e.g. currently > both current baseline_symbols.txt and the ones I've posted don't include the > two TLS: lines, because of the fear that not everyone has TLS enabled. > If baseline_symbols.txt right now miss some symbols, it is not a big deal > if it is not in the base version (with my patch base versions), but with > stricter checking it would complain. Either we'd just say that TLS is > assumed on these targets and add the TLS: lines, or we'd need to invent > some symbol conditionalizing or something. Ah, yes. We will keep on doing the present solution for libstdc++.so.6 and invent something clever later. -benjamin
--- libstdc++-v3/testsuite/util/testsuite_abi.cc.jj 2010-12-13 12:06:14.000000000 +0100 +++ libstdc++-v3/testsuite/util/testsuite_abi.cc 2011-03-21 09:22:13.296401986 +0100 @@ -1,6 +1,6 @@ // -*- C++ -*- -// Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 +// Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 // Free Software Foundation, Inc. // This library is free software; you can redistribute it and/or @@ -217,10 +217,14 @@ check_version(symbol& test, bool added) else test.version_status = symbol::incompatible; - // Check that added symbols aren't added in the base version. - if (added && test.version_name == known_versions[0]) + // Check that added symbols aren't added in the base versions. + if (added + && (test.version_name == known_versions[0] + || test.version_name == "CXXABI_1.3" + || test.version_name == "GLIBCXX_LDBL_3.4" + || test.version_name == "CXXABI_LDBL_1.3")) test.version_status = symbol::incompatible; - + // Check that long double compatibility symbols demangled as // __float128 are put into some _LDBL_ version name. if (added && test.demangled_name.find("__float128") != std::string::npos)