From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7542 invoked by alias); 10 Apr 2003 12:51:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7349 invoked from network); 10 Apr 2003 12:51:05 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 10 Apr 2003 12:51:05 -0000 Received: from prospero.boston.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h3ACp3u07912; Thu, 10 Apr 2003 08:51:03 -0400 Received: by prospero.boston.redhat.com (Postfix, from userid 4046) id 60FF9F7D4A; Thu, 10 Apr 2003 08:49:51 -0400 (EDT) To: Ulrich Drepper Cc: GNU C Library , gcc@gcc.gnu.org Subject: Re: PATCH: Treat RTLD_LOCAL like Solaris (Re: Duplicate data objects in shared libraries) From: Jason Merrill In-Reply-To: (Jason Merrill's message of "Fri, 31 May 2002 00:56:29 -0400") References: <76260000.1021912729@warlock.codesourcery.com> <60630000.1021922077@gandalf.codesourcery.com> <00ba01c20035$805388a0$6601a8c0@boostconsulting.com> <08b101c201f0$d511fd60$6601a8c0@boostconsulting.com> <20020529130945.A16909@lucon.org> <039401c20759$a3ba1400$6601a8c0@boostconsulting.com> <1022790116.22692.205.camel@myware.mynet> Date: Thu, 10 Apr 2003 15:31:00 -0000 Message-ID: User-Agent: Gnus/5.090013 (Oort Gnus v0.13) Emacs/21.2 (i386-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00421.txt.bz2 On Fri, 31 May 2002 00:56:29 -0400, Jason Merrill wrote: >>>>>> "Ulrich" == Ulrich Drepper writes: > > Thanks for responding. > >> On Thu, 2002-05-30 at 13:01, Jason Merrill wrote: > >>> No; Solaris' behavior is no more helpful for real-world C++ examples. > >> Very specialized and maybe true for gcc. > > The EDG frontend, used by Intel among many others, also relies on address > comparison for typeinfos. And, indeed, the Intel compiler produces code > that fails in exactly the same way as the gcc output. > > Intel also seems to use weak symbols, and even linkonce sections, for > template instantiations. > > Sun CC 4.2 fails in the same way under Solaris 5.8 (after I make the > necessary changes to accomodate that ancient compiler; fortunately, it > supports EH). > > Interestingly, SGI CC 7.30 passes the test, even though it also uses the > EDG frontend. I'll investigate why; I'm guessing dlopen works differently > on Irix. > >>> Is there any kind of a standard for ld.so symbol resolution behavior? > >> Most things the generic ELF ABI covers. But the behavior of dlopen() on >> the ELF level is not covered by any standard. > >>> 1) Always prefer the last weak definition if no strong definition is seen. > >> Special weak symbol handling is going away. The ELF spec didn't clearly >> state what has to happen and so a few implementation (like glibc) added >> this kind of support. But it's not portable and it's unnecessarily >> reducing the speed. > > It's not portable because, as you say, there's no standard. That seems > like an opportunity to explore what a future standard should say. > > Speed should not trump correctness. If you have a different idea for how > we can get proper C++ semantics, I'd love to hear it. > >>> 2) If a DSO A has two unrelated dependencies B and C which both define (and >>> use) the same weak symbol, add C to the dependency list of this loaded >>> copy of B. > >> If I understand this correctly you mean > >> A ---> B >> | >> +--> C > >> and B defines and uses 'foo' and C defines and uses 'foo'. > >> In this case it makes no difference whether C gets added to the >> dependency list of B since B's scope comes first. > > Yes, I mentioned that this was only meaningful in conjunction with #1, > which would cause the last definition to be chosen. > >>> 3) When resolving a relocation from a DSO loaded with RTLD_LOCAL, start >>> looking from the DSO itself; do not consider other RTLD_LOCAL objects >>> which depend on it. > >> Starting with the DSO itself is what you select with DF_SYMBOLIC. It's >> generally a very bad idea. Which other scopes are searched depends >> heavily on the actual situation. There won't be any "this is how C++ >> needs it and therefore this is how it's gonna be". > > Of course not, I'm mostly looking for input. But C++ places more complex > demands on the linker, leading to situations that we hadn't considered > before; we need to consider what the right thing to do is in those > situations. I've suggested what I think the right thing is, which I > believe is appropriate for all languages, not just C++, but I'm very > interested in your opinion; you are certainly more familiar with ld.so than > I. > >> I'll look at all this hopefully in two weeks from now. > > Thanks. Ping? Jason