This is the mail archive of the mailing list for the GCC 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: Duplicate data objects in shared libraries

>>>>> "David" == David Abrahams <> writes:

> From: "Jason Merrill" <>

>> ->
>>      ->
>> ->
> No, that's not what I had in mind. In fact I assumed *** that B would get
> the same copy of S that was currently used by U, which is to say the one in
> T. Is there any reason it couldn't work that way?

Because the one in T is not visible when we are loading B.  The symbols
used to satisfy relocs in U are not re-exported by U.

> What I had in mind was more like this:

> ->
> ->

> Now there are two shared spaces (A,T) and (B,U), each with its own copy of
> S. Then:

> ->,

> C wanted a single shared copy but ends up having to choose one or error. I
> vote for the former.

In this case, T and U are already resolved when we load C, so they already
resolve to their own copies.  Under current Linux semantics, C would then
resolve to its own copies; my proposals would cause it to refer to the one
from T.

Under my proposal #7, your example and mine would have the same result.

>> I would further clarify my proposal #6 thus:
>> 7) Resolution of a relocation in a DSO loaded with RTLD_LOCAL only
>> considers definitions in the DSO itself and its dependencies.  If a
>> strong definition is seen in the normal breadth-first search of these
>> DSOs, it is used; otherwise, a weak definition is chosen by depth-first
>> search.

> If you believe Martin, symbols we care about like RTTI info and template
> static members are not weak...

I'm not sure that Martin said that; in any case, it's wrong.  Symbols with
vague linkage are emitted as weak in order to avoid multiple definition
errors in static links.


>> I don't see any way to get to just give us the semantics we want
>> for this subcase.

> What about just following the semantics I had assumed you'd get anyway
> (***)?

Well, that's another possibility.

8) #7, but also consider the prior resolutions of relocs to the same symbol
   in a dependency.

This would fix my example, but not yours.  And I don't think it's as clean
a design as #7 alone.


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