From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31708 invoked by alias); 5 Jun 2008 00:43:46 -0000 Received: (qmail 31700 invoked by uid 22791); 5 Jun 2008 00:43:45 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jun 2008 00:43:21 +0000 Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id m550hA6L019790; Thu, 5 Jun 2008 01:43:10 +0100 Received: from smtp.corp.google.com (spacemonkey2.corp.google.com [192.168.120.114]) by zps35.corp.google.com with ESMTP id m550h7lq005669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 17:43:08 -0700 Received: from localhost.localdomain.google.com (69-36-227-135.cust.layer42.net [69.36.227.135] (may be forged)) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id m550drbG008363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 17:39:56 -0700 To: Nick Kledzik Cc: Chris Lattner , Diego Novillo , GCC Mailing List , Kenneth Zadeck , Jan Hubicka , Rafael Espindola , Ollie Wild , Robert Hundt , Devang Patel Subject: Re: [whopr] Design/implementation alternatives for the driver and WPA References: <96A87E23-CD76-41E3-A4BD-DD399C847F17@apple.com> <48F70208-61C2-4D44-9531-E682C74647E6@apple.com> From: Ian Lance Taylor Date: Thu, 05 Jun 2008 00:43:00 -0000 In-Reply-To: (Nick Kledzik's message of "Wed\, 4 Jun 2008 17\:20\:34 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-06/txt/msg00094.txt.bz2 Nick Kledzik writes: > On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote: >> Nick Kledzik writes: >> >>> I don't claim our current implementation is bug free, but the lto >>> interface >>> matches the Apple linker internal model, so we don't expect and have >>> not encountered any problems mixing mach-o and llvm bitcode files. >> >> Hmmm, OK, how about this example: >> >> a.o: contains LTO information, refers to S >> b.o: no LTO information, defines S >> c.o: contains LTO information, defines S at version V, S/V is not >> hidden >> >> In the absence of b.o, the reference to S in a.o will be resolved >> against the definition of S in c.o. In the presence of b.o, the >> reference to S in a.o will be resolved against the definition of S in >> b.o. >> >> I suppose we could refuse to inline versioned symbols, but that >> doesn't seem desirable since it is normally fine. > > > As Chris mentioned earlier today, the Apple tool chain does not > support versioned symbols. > But if versioned symbols are a naming convention (that is everything > is encoded in > the symbol name), then this would work the same as your previous > example. Namely, > the linker would coalesce away S in c.o, which in turns tell the LTO > engine that it > can't inline/optimize away c.o's S and after LTO is done, the linker > throws away > the LTO generated S and uses b.o's S instead. Versioned symbols are not a naming convention, but they aren't all that different from one. Basically every symbol may have an optional version, and when a symbol has a version the version may be hidden or not. A symbol definition with a hidden version may only be matched by a symbol reference with that exact version. A symbol definition with a non-hidden version definition may be matched by a symbol reference with the same name without a version. This is most interesting in the dynamic linker, of course. How does the linker inform the plugin that the plugin is not permitted to use c.o's S? Ian