This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Fix linkage in libsupc++
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: mark at codesourcery dot com
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: 03 Aug 2004 09:43:55 +0200
- Subject: Re: PATCH: Fix linkage in libsupc++
- Organization: Integrable Solutions
- References: <200408030657.i736vZjn023565@sirius.codesourcery.com>
Mark Mitchell <mark@codesourcery.com> 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
visibility patch is doing something very very *odd*.
An overload set cannot contain two different functions
with a C language linkage. We don't have overloads in C.
If the above code is accepted, then what appears at the global scope
above is a definition for the "f" at __cxxabiv1 scope.
7.5/6
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. Two declarations for an object with C language
linkage with the same name (ignoring the namespace names that
qualify it) that appear in different namespace scopes refer to the
same object. [Note: because of the one definition rule (3.2), only
one definition for a function or object with C linkage may appear in
the program; that is, such a function or object must not be defined
in more than one namespace scope. For example,
namespace A {
extern "C" int f();
extern "C" int g() { return 1; }
extern "C" int h();
}
namespace B {
extern "C" int f(); // A::f and B::f refer
// to the same function
extern "C" int g() { return 1; } // ill-formed, the function g
// with C language linkage
// has two definitions
}
int A::f() { return 98; } // definition for the function f
// with C language linkage
extern "C" int h() { return 97; }
// definition for the function h
// with C language linkage
// A::h and ::h refer to the same function
--end note]
| 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.
I agree with your patch explicitly seeting the visibility, but I do
not agree with the overload bits.
-- Gaby