This is the mail archive of the gcc@gcc.gnu.org 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 Abrahams" <david.abrahams@rcn.com> writes:

> ...as a language extension, right. And some implementations require that a
> symbol be specifically labelled as eligible for such replacement by
> programs, in order to better detect errors.

For C++, it's an extension. For C, 5.1.1.1 specifies

         8.  All  external  object  and  function  references   are
             resolved.   Library  components  are linked to satisfy
             external  references  to  functions  and  objects  not
             defined   in   the   current  translation.   All  such
             translator output is collected into  a  program  image
             which contains information needed for execution in its
             execution environment.

So while it may be an extension to allow programs to define functions
from the standard library, a conforming implementation clearly must
support this feature for other libraries.

> ...and this is expected to work on any symbol without explicit notation, I
> take it, just as with static libs. 

Atleast for malloc, it is clearly necessary to support replacements
that have been defined without any explicit notation, yes.

I now recall the reason for glibc to define all library entry points
as weak, even though the dynamic linker would not reject duplicate
symbols: with that setup, it is possible to define the replacement
malloc in a shared library that happens to be searched *after* the C
library, and to replace malloc even in shared libraries that have not
been linked with the replacement at all.

> If you accepted the idea of implementing a half-measure, I would be
> very happy.

It will be very difficult to convince GCC maintainers to change RTTI
matching, unless problem reports with that semantics pile up
significantly. I believe the rationale is that you can gain speed with
the current implementation, and that giving up that advantage in
favour of providing a minority of users with the illusion of a
solution is not acceptable.

> I need a fix, and I need it sooner than we'll see any change in the
> linker/loader behavior.

Implement your own exception matching, then. Don't rely on the C++
polymorphic exception handling, instead, define a single exception
class that carries all exceptions. Then provide library functions to
perform a more specific matching.

I believe that the notational inconvenience of that approach would be
small, and it would improve portabibility of your code.

> > > For my particular application, they are not. However, *you*
> > > convinced me that nobody was interested in solving my particular
> > > problem, and that developing useful and consistent shared
> > > library semantics for the whole language was a worthwhile goal
> > > (I also have that goal for the standardization process).
> >
> > Good. I was just surprised by this change in mind.
> 
> I'm surprised that you view it as a change. I'll refrain from pointing you
> at my earlier messages like
> http://gcc.gnu.org/ml/gcc/2002-05/msg00995.html<wink> which describe my
> position, but I thought what I wrote was pretty unambiguous.

I don't like these "he said, then I said" games, but in this message,
you said

   You seem to be operating on the assumption that users of shared
   libraries will expect them to be semantically equivalent to
   good-ol'-static linking under all circumstances ...
   Of course, nobody but the most naive users have that expectation.

It appears that you are now expecting that static members in templates
behave like they do in static libraries. Does that make you a most
naive user?

Regards,
Martin


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