http://bugzilla.opensuse.org/show_bug.cgi?id=1187864 http://bugzilla.opensuse.org/show_bug.cgi?id=1187864#c5 --- Comment #5 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Richard Biener from comment #2)

For C there's no ODR so things are more complicated. What about C11 6.9.5?

An external definition is an external declaration that is also a definition of a function (other than an inline definition) or an object. 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. (In reply to Michael Matz from comment #3)

I'm quite heavily opposed to disabling interposition wholesale. In my view this is more about explicitly annotating interposable functions as weak instead of allowing interposition for any function.

Also note that protected visiblity is going to be fixed on x86-64 (to not be worse than default visibility and break with copy relocations, i.e. it will work again like before 2014/15) over the next months. What are the ideas for that? Not doing copy relocations at all, or giving

ELF default visibility has always implied interposability, but I think that's mostly seen as historical artifact by now. Visibility and interposability are pretty much orthogonal. Just because a library is "exporting" functions doesn't mean it's inviting others to replace them. With a few exceptions that makes absolutely no sense, and it wouldn't hurt to mark these exceptions as "weak". protected visibility a different meaning for variables?

At that point packages choosing so can simply use that. It's going to quite a bit of time for packages to migrate to this.

I get your point, default visibility has never been a good default, and it's probably hopeless to save it. Protected visibility is more or less defined as non-interposable export, so that and hidden visibility should satisfy nearly all uses. Default visibility could still be used for the rare case where a function should actually be interposable. But I think that's what library writers have (in almost all cases) always wanted, but didn't use it because it didn't work and was recommended against. (GCC's man page says "protected and internal are pretty useless in real-world usage so the only other commonly used option is hidden." Drepper writes: "Only the first two [default and hidden] should ever be used.") Still, protected visibility just doesn't interpose, it doesn't error out if there is a function with the same name. So while library writers can use it to opt out of interposition (which they probably didn't want in the first place), those who'd want to interpose just get a silent failure just as if we were making -fno-semantic-interposition the default. If library writers know about their users and whether someone might interpose their functions that could be helpful, but I don't know how often that's the case. In any event, if library writers want to actively allow interposition, an explicit "weak" attribute would communicate that intent clearly. -- You are receiving this mail because: You are on the CC list for the bug.