This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Fix linkage in libsupc++

Gabriel Dos Reis wrote:

Mark Mitchell <> writes:

| With the new symbol visibility patches, we have to be careful not to
| get incorrect linkage in the libraries; if the default visibility is
| not "default" when we include the headers, things get confused.
| Things are even worse for ports that use "hidden" visibility by
| default; the ARM/Symbian OS port will be one such.
| | A tricky problem here was that this pattern was present in a lot of
| the libsupc++ files:
| | // cxxabi.h
| | namespace __cxxabiv1 { | extern "C" void f();
| }
| | // f.c
| | #include <cxxabi.h>
| | extern "C" void f() {}
| | This is *not* a definition of the function declared in the header;
| it's just an overloaded function. You must write "__cxxabiv1::f" or
| put the definition inside the namespace.

If the "visibility" patch does something like that, then the

It's not the visibility patch that causes this; these declarations were never being matched up before, either. It just didn't matter before.

I have looked at this part of the standard before, and despite the language that you cite, I am not convinced that in my example above the compiler should check that the two declarations of "f" match. For example, if the first were "void f(int)" must the compiler issue an error? I think that program is ill-formed, because of the language you cite, but I see nothing that would cause name lookup for the definition to find the version in the namespace.

If the committee disagrees with me, then we have a compiler bug. Still, the change I made to the library is at worst harmless.

At most one function with a particular name can have C language
linkage. Two declarations for a function with C language linkage
with the same function name (ignoring the namespace names that
qualify it) that appear in different namespace scopes refer to the
same function.

| I did not attempt to fix all of the V3 headers; I'm only concerned
| with libsupc++ at the moment.  However, similar changes should
| probably be made throughout V3.  Otherwise, linkage will be wrong if
| people #include (say) <iostream> with a non-default symbol visibility.

I'm not convinced by your example and the rationale you gave. What am
I missing? Most certainly, in your example ::f and __cxxabiv1::f
refer to the same function and we should have &::f == &__cxxabiv1::f.

That's a separate issue. You still want the visibility #pragmas in the V3 headers; otherwise, for example, copies of the type info for iostream in user programs may not be merged with that in the library, if the user does:

 #pragma GCC visibility push(hidden)
 #include <iostream>

The only reason I explicitly qualified the names in libsupc++ is that otherwise the visibility declarations in the header did not -- in practice -- apply to the definitions in the .cc files due to the issues above.


Mark Mitchell
CodeSourcery, LLC
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]