From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28069 invoked by alias); 18 Dec 2006 08:24:54 -0000 Received: (qmail 28059 invoked by uid 22791); 18 Dec 2006 08:24:53 -0000 X-Spam-Check-By: sourceware.org Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com) (61.144.161.55) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Dec 2006 08:24:46 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAG00E24ND1C3@szxga03-in.huawei.com> for gcc-help@gcc.gnu.org; Mon, 18 Dec 2006 16:24:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAG00FFVND1OE@szxga03-in.huawei.com> for gcc-help@gcc.gnu.org; Mon, 18 Dec 2006 16:24:37 +0800 (CST) Received: from [127.0.0.1] ([10.18.18.211]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JAG00G04NCZVL@szxml04-in.huawei.com> for gcc-help@gcc.gnu.org; Mon, 18 Dec 2006 16:24:37 +0800 (CST) Date: Mon, 18 Dec 2006 08:24:00 -0000 From: jimmy Subject: Re: dead function elimination In-reply-to: <4559B37E.5070405@redhat.com> To: Nick Clifton Cc: binutils@sourceware.org, gcc-help@gcc.gnu.org Message-id: <4586503E.3010108@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) References: <4552DE07.5050702@huawei.com> <4552EB64.20000@redhat.com> <4552F092.7020405@huawei.com> <4559B37E.5070405@redhat.com> Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2006-12/txt/msg00271.txt.bz2 Nick Clifton wrote: > Hi Jimmy, > >> I thght the linker alone was supposed to be able to do >> dead-procedure-elimination. > > No. It is a nice feature, but it is not a requirement of a linker. > >> After all can't the linker determine which procedures are unreferenced >> in the final executable? > > Which is exactly what the --ffunction-sections and --gc-sections > switches do. > >> If i'm not mistaken the diablo linker can do this? > > It probably can. > > Cheers > Nick > If i understand things correctly, there is a restriction on '--gc-sections' that it doesn't work if the link is dynamic. What if my scenario is like this: libsomething.a - some static library built with -ffunction-sections & -fdata-sections src.o - my source code also built with -ffucntion-sections final step: ld -o exec --gc-sections src.o -lsomething In the above step, ld simply says '/usr/bin/ld: Warning: gc-sections option ignored' My aim here was to remove unreferenced functions from both my code & the static library, but at the same time using libc as an '.so' (obviously that makes sense, cos it's shared across many apps & probably not built with -ffunction-sections to use a static link). Is there any way to achieve this? -jb -- mathematician, n.: Some one who believes imaginary things appear right before your i's.