From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11236 invoked by alias); 17 Nov 2005 01:28:09 -0000 Received: (qmail 11229 invoked by uid 22791); 17 Nov 2005 01:28:07 -0000 Received: from dumbledore.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.11) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 01:28:07 +0000 Received: (qmail 30605 invoked from network); 17 Nov 2005 01:28:06 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Nov 2005 01:28:06 -0000 Message-ID: <437BDC9E.3080608@codesourcery.com> Date: Thu, 17 Nov 2005 01:28:00 -0000 From: Mark Mitchell User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Richard Henderson CC: gcc mailing list Subject: Re: Link-time optimzation References: <437BB214.1070306@codesourcery.com> <20051117011900.GA17847@redhat.com> In-Reply-To: <20051117011900.GA17847@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2005-11/txt/msg00749.txt.bz2 Richard Henderson wrote: In general, I'm going to just collect comments in a folder for a while, and then try to reply once the dust has settled a bit. I'm interested in seeing where things go, and my primary interest is in getting *some* consensus, independent of a particular one. But, I'll try to answer this: > In Requirement 4, you say that the function F from input files a.o and > b.o should still be named F in the output file. Why is this requirement > more than simply having the debug information reflect that both names > were originally F? I see you go to some length in section 3 to ensure > actual symbol table duplicates, and I don't know why. Our understanding was that the debugger actually uses the symbol table, in addition to the debugging information, in some cases. (This must be true when not running with -g, but I thought it was true in other cases as well.) It might be true for other tools, too. It's true that, from a correctness or code-generation point of view, it shouldn't matter, so, for non-GNU assemblers, we could fall back to F.0/F.1, etc. > The rest of the requirements look good. I cannot immediately think of > anything you've forgotten. Thanks! -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304