From owner-freebsd-emulation Tue May 6 23:48:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA05777 for emulation-outgoing; Tue, 6 May 1997 23:48:18 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA05768 for ; Tue, 6 May 1997 23:48:14 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.5/8.7.3) id IAA05457; Wed, 7 May 1997 08:48:39 +0200 (MEST) From: Søren Schmidt Message-Id: <199705070648.IAA05457@sos.freebsd.dk> Subject: Re: Linux-emul LDT support (implementation question(s)) In-Reply-To: <199705070517.OAA18353@genesis.atrad.adelaide.edu.au> from Michael Smith at "May 7, 97 02:47:58 pm" To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 7 May 1997 08:48:33 +0200 (MEST) Cc: emulation@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Michael Smith who wrote: > > Hokay, following through on the question raised the other day about > emulating the Linux i386_modify_ldt() function, I'm prodding at it > currently and have the odd question or two... OK, I'd be willing to help test it :), I got into a long mail exchange with Ola, nice guy... > Firstly, the BSD functions i386_get_ldt() and i386_set_ldt() use > copyin/copyout on their parameters. Is this going to be a problem > if the parameters are alreay in the kernel (I expect not, as otherwise > it would be a horrific problem for many other functions). I shouldn't pose a problem.. > Secondly, Linux has : > > #define MODIFY_LDT_CONTENTS_DATA 0 > #define MODIFY_LDT_CONTENTS_STACK 1 > #define MODIFY_LDT_CONTENTS_CODE 2 > > Where we have : > > /* memory segment types */ > #define SDT_MEMRO 16 /* memory read only */ > #define SDT_MEMROA 17 /* memory read only accessed */ > #define SDT_MEMRW 18 /* memory read write */ > #define SDT_MEMRWA 19 /* memory read write accessed */ > #define SDT_MEMROD 20 /* memory read only expand dwn limit */ > #define SDT_MEMRODA 21 /* memory read only expand dwn limit accessed */ > #define SDT_MEMRWD 22 /* memory read write expand dwn limit */ > #define SDT_MEMRWDA 23 /* memory read write expand dwn limit accessed * > / > #define SDT_MEME 24 /* memory execute only */ > #define SDT_MEMEA 25 /* memory execute only accessed */ > #define SDT_MEMER 26 /* memory execute read */ > #define SDT_MEMERA 27 /* memory execute read accessed */ > #define SDT_MEMEC 28 /* memory execute only conforming */ > #define SDT_MEMEAC 29 /* memory execute only accessed conforming */ > #define SDT_MEMERC 30 /* memory execute read conforming */ > #define SDT_MEMERAC 31 /* memory execute read accessed conforming */ > > Govelling in i386/i386/machdep.c suggests that data should be MEMRWA > and code should be MEMERA. How about the stack? Is it the same as > the data segment? Think so, yes.. > There's also a 'read_exec_only' flag; anyone with the Linux kernel source > care to shed some light on how this is translated to a "real" LDT? Have to go look, but I think we might treat many little details differently, sigh, I'm currently (in the sparse spare hours) looking at getting trace to work (so we can debug linux bins), not easy, to many little subtle differences... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end ..