From fnaumann@mail.cs.uni-magdeburg.de Wed Jun 30 17:54:30 2004 Message-ID: <40E2E1A4.5020309@imperia.net> Date: Wed, 30 Jun 2004 17:52:04 +0200 From: Guido Flohr User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: de, ru, ar, en-us, en, fr MIME-Version: 1.0 To: Mint list Subject: Re: [MiNT] -fPIC References: <20040213215924.074001d9.mandin.patrice@wanadoo.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new using F-Secure Antivirus at imperia.net X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at fishpool.fi Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: guido@imperia.net Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prinz.cs.uni-magdeburg.de id i5UFs9m4013130 Hi, Standa Opichal wrote: > Hmm, PIC? How's the code generated by a current gcc 2.95.x supported by > SpareMiNT dependent on a memory address that is loaded to? We don't have > VM and so we do relocation by each exec(), right? > > In case the binary is made using -fPIC. Do we have to do any relocation at > all? You have to distinguish between two fundamentally different types of relocations. The linker relocates addresses in the various object files, i. e. it replaces references to abstract symbol names with the real address references. This is always needed because the compiler does not know about the order the various object files are later linked together. Other operating systems are ready here, since their executables have a constant start address. This start address is virtual, the mapping between virtual and physical addresses is handled by the MMU. TOS is different. Each process can (should) have its distinct address space and therefore a distinct start address. Attached to the image on disk is a table with file offsets (also called "relocation table" although it is a completely different kind of relocation), that have to be corrected by the offset from the program basepage in physical memory minus the constant start address that was assumed while linking. Theoretically (I think so) the second type of relocation could be avoided. But this would result in bigger and slower executables. And you still weren't able to share anything. Ciao Guido -- Imperia AG, Development Leyboldstr. 10 - D-50354 Hürth - http://www.imperia.net/