This is the mail archive of the
mailing list for the GCC project.
Re: ELF interposition and One Definition Rule
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, nathan at codesourcery dot com
- Date: Mon, 26 Aug 2013 20:16:23 -0500
- Subject: Re: ELF interposition and One Definition Rule
- Authentication-results: sourceware.org; auth=none
- References: <20130826152141 dot GA19918 at kam dot mff dot cuni dot cz> <521BF9C1 dot 8080806 at redhat dot com>
On Mon, Aug 26, 2013 at 7:58 PM, Jason Merrill <email@example.com> wrote:
> On 08/26/2013 11:21 AM, Jan Hubicka wrote:
>> Our default behaviour special case inline functions that are always
>> AVAIL_AVAILABLE and, via decl_replaceable_p, also any COMDAT (that may be
>> functions since all COMDATs are also inlines, but makes difference for
>> variables I think).
> Not all COMDAT functions are inlines; template instantiations are also
>> My understanding of C++ One Definition Rule, in a strict sense, does not a
>> allow in to define two functions of the same name and different semantics
>> in a
>> valid program.
> Strictly speaking, the same is true of C:
> "If an identifier declared with external linkage is used in an expression
> (other than as part of the operand of a sizeof or _Alignof operator whose
> result is an integer constant), somewhere in the entire program there shall
> be exactly one external definition for the identifier; otherwise, there
> shall be no more than one."
>> I also think that all DSOs eventually linked together or
>> dlopenned are part of the same program. So theoretically, for C++
>> code, we may go with AVAIL_AVAILABLE everywhere.
> And for C code as well.
C++'s ODR is much stronger than C's though. For example, C
allows definitions for the same inline function to differ -- the
out-of-line extern definition does not need to be the same.
That is anathema in C++.
> ELF symbol replacement is an extension to C/C++ semantics, which does not
> include DSOs; it seems to me that it is up to us to define what assumptions
> we want the compiler to be able to make.
>> On IRC we got into an agreement that we may disallow interposition for
>> virtuals, since replacing these seems fishy - they don't even have address
>> defined and compiler can freely duplicate and/or unify them. I think same
>> apply for C++ constructors and destructors now.
> But it would be simple to create a DSO which replaces a virtual function or
> a constructor, by simply providing a new definition. Since interposition
> happens outside the language, I don't think reasoning based on things that
> happen within the language makes much sense.
>> Of course I would be happier with a stronger rule - for instance allowing
>> interposition only on plain functions not on methods.
> Existing uses of interposition apply to plain functions, but that doesn't
> mean someone might not want to use it for member functions as well.
> I would be happy with an even stronger default that optimizes on the
> assumption that no interposition occurs; typically interposition is
> overriding a symbol found in a dynamic library (i.e. malloc) rather than a
> symbol defined in the same translation unit as the use.
Again, strongly agreed.