From mint-bounce@lists.fishpool.fi  Sat Oct 30 23:29:33 2004
X-Original-To: fnaumann@mail.boerde.de
Delivered-To: fnaumann@mail.boerde.de
Date: Sat, 30 Oct 2004 23:30:14 +0200
From: Patrice Mandin <mandin.patrice@wanadoo.fr>
To: Mint list <mint@fishpool.com>
Subject: Re: [MiNT] Shareable/loadable libraries: a preliminary document
Message-Id: <20041030233014.0fa3d0eb.mandin.patrice@wanadoo.fr>
In-Reply-To: <0322B8A2-2AB7-11D9-91AD-00039357F826@epfl.ch>
References: <20041029210939.1d32bc21.mandin.patrice@wanadoo.fr>
	<693A750D-29E7-11D9-B308-00039357F826@epfl.ch>
	<20041030211600.422fdada.mandin.patrice@wanadoo.fr>
	<0322B8A2-2AB7-11D9-91AD-00039357F826@epfl.ch>
Organization: Chez moi
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
X-ecartis-version: Ecartis v1.0.0
Sender: mint-bounce@lists.fishpool.fi
Errors-To: mint-bounce@lists.fishpool.fi
X-original-sender: mandin.patrice@wanadoo.fr
Precedence: bulk
List-help: <mailto:ecartis@lists.fishpool.fi?Subject=help>
List-unsubscribe: <mailto:mint-request@lists.fishpool.fi?Subject=unsubscribe>
List-Id: <mint.lists.fishpool.fi>
X-List-ID: <mint.lists.fishpool.fi>
X-Virus-Scanned: by amavisd-new at relay.boerde.de
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de
X-Spam-Status: No, hits=-0.9 tagged_above=-50.5 required=3.8 tests=BAYES_00,
 RCVD_IN_SORBS
X-Spam-Level: 

Le Sat, 30 Oct 2004 23:02:30 +0200
Philipp Donz=E9 <philipp.donze@epfl.ch> a =E9crit:

> > Even if an executable has only one translation table, you know the=20
> > size of the TEXT segment, so you know if you are relocating an address
> > in the TEXT or the DATA segment, so you can align the segments on MMU
> > pages boundaries.
>=20
> But this doesn't work if the compiler generates PC relativ addresses.=20
> E.g. "move.l data(PC), D0" can't work correctly if the assembler does=20
> not know the correct offset to generate.
> I must admit, I'm new to GCC. But Pure C makes extensive use of PC=20
> relativ addressing modes. (=3D> this gives smaller and faster code)

You're right, I did not think of the case of relative to PC. But I don't
know if gcc generate this type of code or not to access the DATA segment.
You talk about PureC, but I don't know if creating dynamic linked
libraries will be possible with it, so I just stick with binutils+gcc.
And on Linux, the segments are aligned on a page boundary to make the TEXT
segment read-only, so either it is done:
- in the file
- no relative to PC when accessing a different segment

--=20
Patrice Mandin
WWW: http://membres.lycos.fr/pmandin/
Programmeur Linux, Atari
Sp=E9cialit=E9: D=E9veloppement, jeux


