Re: ELF interposition and One Definition Rule

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Mon, Aug 26, 2013 at 7:58 PM, Jason Merrill <jason@redhat.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
>> for
>> functions since all COMDATs are also inlines, but makes difference for
>> variables I think).
>
>
> Not all COMDAT functions are inlines; template instantiations are also
> COMDAT.
>
>
>> 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++
>> produced
>> 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
>> well
>> 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.

Agreed.

>
> 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.
>
> Jason
>

Again, strongly agreed.

-- Gaby