[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #3 from Niall Douglas s_gccbugzilla at nedprod dot com 2012-06-15 15:13:37 UTC --- (In reply to comment #1) There's no point differentiating the gnu variants, they don't have any ABI impact. They don't have any ABI impact that we know of at the present time in this present generation of GCCs. As a debug aid that's likely to be there from now on and forever, who's to say about the future. Better to cover all bases now I'd say, just in case. This could (and probably should) be done in the library because the output of G++ is ABI compatible, it's only standard library components that are not. There are no shortage of third party libraries which enable special new stuff when compiled with GNU additions turned on. Also, the ISO C++ standard is quite clear that ABI between C++03 and C++11 compiled code is not guaranteed in the case where C++11 libraries/shared objects are linked into a C++03 compiled program. Indeed, really an error ought to be thrown if this happens for safety's sake, a warning as a minimum. Niall
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #4 from Niall Douglas s_gccbugzilla at nedprod dot com 2012-06-15 15:23:21 UTC --- (In reply to comment #2) you can use -frecord-gcc-switches to detect mixed objects in linked library. Indeed, one could grok the .text section this adds, parse the command line and determine the build settings. However, this is why that would be a poorer choice: 1. Last time I looked record-gcc-switches only works with ELF outputs. 2. You can't debug prebuilt system provided shared objects as these won't have been compiled with -frecord-gcc-switches. 3. Parsing an ELF .text section is hard from within programs as compared to dlsym(dll, __gplusplus_std_cplusplus11) 4. Automated build config tools already have machinery for seeing if some symbol is exported by some binary object. That lets the proposed system fit into said existing machinery easily, whereas groking .text sections is considerably harder. For example, an automated build config might adapt how it builds itself according to how system provided shared libraries were built. 5. Future GCC command line switches may change. Indeed, one day -std will default to c++11, not c++98. When that happens your .text section parsing will break. The proposed system doesn't have that problem and is more futureproof. Niall
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15 15:37:34 UTC --- (In reply to comment #3) (In reply to comment #1) There's no point differentiating the gnu variants, they don't have any ABI impact. They don't have any ABI impact that we know of at the present time in this present generation of GCCs. As a debug aid that's likely to be there from now on and forever, who's to say about the future. The GCC maintainers are to say. Better to cover all bases now I'd say, just in case. There's no point adding (and maintaining) yet another feature to handle hypothetical differences which *by*design* should not happen. Far more relevant than c++11 vs gnu++11 is -fabi-version=n, which your scheme doesn't cover. This could (and probably should) be done in the library because the output of G++ is ABI compatible, it's only standard library components that are not. There are no shortage of third party libraries which enable special new stuff when compiled with GNU additions turned on. Not GCC's problem, and no different to libraries which enable new things when -fno-rtti or -fno-exceptions is used Also, the ISO C++ standard is quite clear that ABI between C++03 and C++11 compiled code is not guaranteed in the case where C++11 libraries/shared objects are linked into a C++03 compiled program. Indeed, really an error ought to be thrown if this happens for safety's sake, a warning as a minimum. [citation needed] ;) The standard says nothing about libraries/shared objects It's entirely possible to use G++ to build 100% ABI compatible applications using a mixture of -std=c++98 and -std=c++11 objects, if you don't use the parts of the standard library that are incompatible. A mandatory or warning would cause problems for anyone doing that.
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #6 from Niall Douglas s_gccbugzilla at nedprod dot com 2012-06-15 16:53:01 UTC --- (In reply to comment #5) They don't have any ABI impact that we know of at the present time in this present generation of GCCs. As a debug aid that's likely to be there from now on and forever, who's to say about the future. The GCC maintainers are to say. It's safer to fail safe. And no maintainer is omniscient. Better to cover all bases now I'd say, just in case. There's no point adding (and maintaining) yet another feature to handle hypothetical differences which *by*design* should not happen. There's the ideal world and there's the real world. This is a very likely ongoing real world problem whose fix requires perhaps five lines of new code - hardly a big new feature requiring umpteen lines of code. I'd write the patch myself except I'd put those five lines in the wrong place because GCC's code base is so monolithic. Technically, you could add it to the top of stddef.h or whatever is a guaranteed included library header: #if defined(__cpluscplus) and __cplusplus==201103L extern C void __gplusplus_std_cplusplus11() __attribute__ ((weak)); #elif defined(__cpluscplus) and __cplusplus==199711L extern C void __gplusplus_std_cplusplus97() __attribute__ ((weak)); #elif ... #else #error Unknown C++ variant, cannot set magic symbol #endif ... assuming that compiles which I can't test on this laptop. Far more relevant than c++11 vs gnu++11 is -fabi-version=n, which your scheme doesn't cover. ABI is a GCC issue :). I'd certainly recommend it for that too. You may need to bump ABI if needed to solve C++11 and C++03 interop and a way for checking for that would also be useful. There are no shortage of third party libraries which enable special new stuff when compiled with GNU additions turned on. Not GCC's problem, and no different to libraries which enable new things when -fno-rtti or -fno-exceptions is used Look, it's a debug aid, and if GCC offers special extra features then it's GCC's problem if libraries use them. In the future GCC is going to see lots of C++11 bugs submitted. You're going to ask the question are you *really* sure you compiled everything with C++11?. Right now they'll say yes, but they may well be wrong. This debug aid is as much for your future sanity as anything. Also, the ISO C++ standard is quite clear that ABI between C++03 and C++11 compiled code is not guaranteed in the case where C++11 libraries/shared objects are linked into a C++03 compiled program. Indeed, really an error ought to be thrown if this happens for safety's sake, a warning as a minimum. [citation needed] ;) :) ... I don't suppose you'd take my word as ISO SC22 convenor for Ireland would you? ;) No, it's fair enough, I only know that from watching the discussions on ISO and I have no idea if it's actually written in the final published standard. It is however written in Nicolai Josuttis' updated C++11 The C++ standard library in the chapter on C++11 core language changes. And if you think it through, there has to be in practice ABI breakage in 03 ABIs because no one could have anticipated during their design of what 11 would require [1]. [1]: This may not apply to GCC as it revised its ABI quite recently, and I'm sure its designers took into account likely future 11 requirements. The standard says nothing about libraries/shared objects I know only too well. I have an early draft for shared library implementation on my desk for WG14. It's too ambitious for WG14 as it explicitly adds interop for non-C languages. It's entirely possible to use G++ to build 100% ABI compatible applications using a mixture of -std=c++98 and -std=c++11 objects, if you don't use the parts of the standard library that are incompatible. A mandatory or warning would cause problems for anyone doing that. Sure. Any C++ implementation may choose to go beyond what is needed. However, I personally can see lots of potential for monsters to lurk there. I think the proposed debug aid will save a lot of time for a lot of people in the long run, and for the cost of implementation and almost nil cost of maintenance I'd just go ahead and implement it if I were ye. Which I'm not, so all I can do is try to persuade and advocate. Niall
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15
17:46:51 UTC ---
(In reply to comment #6)
Technically, you could add it to the top of stddef.h or whatever is a
guaranteed included library header:
libstdc++'s bits/c++config.h would be the right place and as part of the std
lib the symbol should probably be named __glibcxx_blah
I think you'd also need an actual definition or nothing will be emitted for the
declaration alone:
#if __GXX_WEAK__
#if __cplusplus == 201103L
extern C void __glibcxx_std_cxx11() __attribute__((weak));
extern C void __glibcxx_std_cxx11() { }
#else if __cplusplus == 199711L
extern C void __glibcxx_std_cxx98() __attribute__((weak));
extern C void __glibcxx_std_cxx98() { }
#else
#warning Unknown C++ standard version
#endif
#endif
No, it's fair enough, I only know that from watching the discussions on ISO
and
I have no idea if it's actually written in the final published standard. It is
however written in Nicolai Josuttis' updated C++11 The C++ standard library
in the chapter on C++11 core language changes. And if you think it through,
there has to be in practice ABI breakage in 03 ABIs because no one could have
anticipated during their design of what 11 would require [1].
[1]: This may not apply to GCC as it revised its ABI quite recently, and I'm
sure its designers took into account likely future 11 requirements.
The current G++ ABI is eight years old and (modulo bugs) the same for c++98 and
c++11, see Bug 53646 comment 17
Again, the incompatibilities are in the library not the core language.
Whether that's generally true for other compilers is irrelevant here.
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-14 17:21:45 UTC --- There's no point differentiating the gnu variants, they don't have any ABI impact. This could (and probably should) be done in the library because the output of G++ is ABI compatible, it's only standard library components that are not.
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-06-14 20:06:15 UTC --- (In reply to comment #0) Can we have a magic weak symbol output by G++ into compilands saying what -std setting was used? For example: No -std outputs __gplusplus_std_cpluscplus98 -std=c++03 outputs __gplusplus_std_cplusplus03 -std=gnu++03 outputs __gplusplus_std_gnu03 -std=c++11 outputs __gplusplus_std_cplusplus11 -std=gnu++11 outputs __gplusplus_std_gnu11 ... and so on ... Why? Because right now it's too easy to accidentally link object files compiled with 98 with those compiled with 11 and not then know why things spontaneously fail: http://gcc.gnu.org/ml/gcc/2012-06/msg00201.html http://gcc.gnu.org/wiki/Cxx11AbiCompatibility If __gplusplus_std_cpluscplus98 and __gplusplus_std_cplusplus11 both turn up in a shared object or executable, then we know we have combined 98 and 11 built code. Indeed, a future ld could warn if this happens. Niall you can use -frecord-gcc-switches to detect mixed objects in linked library.
