From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA02902 for caml-red; Sun, 3 Dec 2000 23:05:40 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA25842 for ; Thu, 30 Nov 2000 17:12:36 +0100 (MET) Received: from cremant.inria.fr (cremant.inria.fr [128.93.8.143]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id eAUG8bf19372; Thu, 30 Nov 2000 17:08:37 +0100 (MET) Received: (from lefessan@localhost) by cremant.inria.fr (8.11.0/8.11.0) id eAUG8WD21137; Thu, 30 Nov 2000 17:08:32 +0100 X-Authentication-Warning: cremant.inria.fr: lefessan set sender to fabrice.le_fessant@inria.fr using -f From: Fabrice Le Fessant MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14886.31615.260102.716998@cremant.inria.fr> Date: Thu, 30 Nov 2000 17:08:31 +0100 (CET) To: John Max Skaller Cc: Vitaly Lugovsky , caml-list@inria.fr Subject: Re: Dynamic loading. Again. References: <14885.12770.825697.215308@cremant.inria.fr> <3A25FB93.AD27098B@ozemail.com.au> X-Mailer: VM 6.75 under Emacs 20.7.1 Reply-To: fabrice.le_fessant@inria.fr Sender: weis@pauillac.inria.fr > Fabrice Le Fessant wrote: > > > > Last year, Mark Hayden and I did some work on dynamic linking of > > native code for Linux. It worked, with few modifications in the > > compiler to generate relocatable code in the ELF format, but the code > > was really big (something like twice the normal size) and really slow > > (about twice slower). > > Do you know why it was slower?? > > Normally, static and load time linkage produce identical code, > and the code doesn't have to be position independent: any code can > be shared, and have distinct per process data at the same virtual > address. Absolute addresses are relocated by patching once at load time. > What's usually required is segmentation (splitting the code into > executable > and data segments). Well, you are right. You don't need to generate position independent code, but it is better if you want the code to be shared between processes. Otherwise, each process has its own code, and a shared library is not that shared ... The problem with generating position independent code is that you need one register for the GOT pointer. One the i386 arch, this is a big penalty. Moreover, all function calls are indirect (we did not optimize for the case of "static" functions), and the GOT must be saved and re-computed -- if used -- at every function entry point, since it is different for each module. I think some optimizations should probably improve this a lot ! - Fabrice Homepage: http://pauillac.inria.fr/~lefessan