From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 7611BBB9A for ; Wed, 9 Nov 2005 13:43:38 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jA9ChbmN003664 for ; Wed, 9 Nov 2005 13:43:38 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA11790 for ; Wed, 9 Nov 2005 13:43:37 +0100 (MET) Received: from comtv.ru (mail.comtv.ru [217.10.32.19]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jA9Chaff015417 for ; Wed, 9 Nov 2005 13:43:37 +0100 X-UCL: actv Received: from av1474.oops ([10.0.66.9] verified) by comtv.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 96443739; Wed, 09 Nov 2005 15:43:37 +0300 Date: Wed, 9 Nov 2005 15:44:01 +0300 (MSK) From: malc X-X-Sender: malc@home.oyster.ru To: Dmitry Bely Cc: caml-list@inria.fr Subject: Re: [Caml-list] No unused code linking? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 4371EEF9.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 4371EEF8.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; malc:01 malc:01 pulsesoft:01 caml-list:01 pulsesoft:01 stdlib:01 otherlibs:01 gcc's:01 ocamlopt:01 compiler:01 ocaml:01 pointers:01 externally:01 cmx:01 ocaml:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 On Wed, 9 Nov 2005, Dmitry Bely wrote: > malc writes: > >>> I am thinking of reducing the size of ocamlopt-generated executables that >>> easily grows to 1Mb and above. The problem as I see it is that any module is >>> linked as a single whole (as all its functions are placed into the single >>> object file), no matter what is actually used. So almost all >>> stdlib/otherlibs become quickly linked into even not very complex project. >>> >>> In C world there is a solution that lets the linker to do its job smartly >>> for monolitic object files: place each function into the separate section >>> (gcc's "-ffunction-sections" or msvc's "-Gy" options) and then ask linker >>> to eliminate unused sections during the link stage. Can anything similar be >>> done with Ocamlopt compiler? >>> >>> Of course, placing each function into the separate section is not a problem - >>> modifications of the code generator would be minimal. The real problem are >>> the frame tables - the single table references all functions in the >>> module. Maybe they can be split and linked separately? What Ocaml >>> developers think of that? >> >> I have played with this idea myself, the problem is not only frametables >> but also the module header (which more or less contains pointers to all >> externally visible(don't take my word on it, been a while, might as well >> be ALL) symbols. > > IMHO, each header item can be placed into the separate DATA section, so > it's not the real problem (the frame table is). No it can not. The moduler header must be contiguous and not rearranged by linker. In absence of .cmx (and name -> mangled name table) OCaml uses the header to call functions by position. Thus, as it is now, no part of header can be eliminated, which in reality means that almost everything, from linkers perspective, is reachable and can not be removed by --gc-functions. > >> All in all this would require quite an effort in restructuring almost >> everything. I wouldn't count on it. > > Probably you are right, but I still hope for a miracle :-) > Right rigth, that's exactly what's required -- mailto:malc@pulsesoft.com