[Bug c++/53673] New: Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems

[Bug c++/53673] New: Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems

[s_gccbugzilla at nedprod dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673

             Bug #: 53673
           Summary: Add magic weak symbol to indicate C++ standard setting
                    (C++03, C++11 etc) to help debug ABI problems
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: s_gccbugzilla@nedprod.com


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

[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems

[redi at gcc dot gnu.org]

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

[pluto at agmk dot net]

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.

[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems

[s_gccbugzilla at nedprod dot com]

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

[s_gccbugzilla at nedprod dot com]

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

[redi at gcc dot gnu.org]

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

[s_gccbugzilla at nedprod dot com]

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

[redi at gcc dot gnu.org]

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 libstdc++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems

[s_gccbugzilla at nedprod dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673

Niall Douglas <s_gccbugzilla at nedprod dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libstdc++

--- Comment #8 from Niall Douglas <s_gccbugzilla at nedprod dot com> 2012-06-16 14:19:18 UTC ---
(In reply to comment #7)
> (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

Do I take this as your support of the above patch to bits/c++config.h? Or do
you still feel it unnecessary?

Niall

[Bug libstdc++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-06-18 00:06:29 UTC ---
I'm ambivalent.

[Bug libstdc++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems

[s_gccbugzilla at nedprod dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673

--- Comment #10 from Niall Douglas <s_gccbugzilla at nedprod dot com> 2012-06-18 10:01:19 UTC ---
(In reply to comment #9)
> I'm ambivalent.

Ok then. Well, thanks for all your help and very useful input. As we have
something now which is very close to a code patch, I suppose we leave it for
now and see how the issue tracks into the future.

I encourage anyone supporting the addition of this feature, or otherwise having
C++11 and C++98 interop problems to subscribe here and to indicate their
support. If you don't indicate support it won't get added.

If we get enough support I'm happy to write the documentation patch. Not so the
code patch - too much paperwork as I learned the hard way last time with my
-fvisibility=X patch :)

Thanks,
Niall

[Bug libstdc++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-06-18 14:22:05 UTC ---
Please don't just use this PR for "me too" comments about interoperability