From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dhog the corruptor!
From: forsyth@caldo.demon.co.uk
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-xktegibywnghqeehkcijpvhtjw"
Message-Id: <20011113234922.7D67919A46@mail.cse.psu.edu>
Date: Tue, 13 Nov 2001 23:54:12 +0000
Topicbox-Message-UUID: 21e108e0-eaca-11e9-9e20-41e7f4b1d025

This is a multi-part message in MIME format.
--upas-xktegibywnghqeehkcijpvhtjw
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

type checking is often ignored in these interfaces.
with static linking #include and mk are often adequate if
not perfect, but dynamic linking increases the chances for
error.


--upas-xktegibywnghqeehkcijpvhtjw
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <9fans-admin@cse.psu.edu>
Received: from punt-2.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk
          id 1005694183:20:09676:2; Tue, 13 Nov 2001 23:29:43 GMT
Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-2.mail.demon.net
           id aa2105837; 13 Nov 2001 23:29 GMT
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 7D6DB19A45; Tue, 13 Nov 2001 18:29:11 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from barf.ugcs.caltech.edu (barf.ugcs.caltech.edu [131.215.43.157])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 8977A199B9
	for <9fans@cse.psu.edu>; Tue, 13 Nov 2001 18:28:43 -0500 (EST)
Received: by barf.ugcs.caltech.edu (Postfix, from userid 2738)
	id C7CAC9C404; Tue, 13 Nov 2001 15:28:42 -0800 (PST)
Received: from barf.ugcs.caltech.edu (localhost [127.0.0.1])
	by barf.ugcs.caltech.edu (Postfix) with ESMTP for <9fans@cse.psu.edu>
	id 77C659C403; Tue, 13 Nov 2001 15:28:37 -0800 (PST)
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dhog the corruptor!
In-Reply-To: Your message of "Tue, 13 Nov 2001 18:04:46 EST."
             <20011113230455.25131199B9@mail.cse.psu.edu>
Message-Id: <20011113232842.C7CAC9C404@barf.ugcs.caltech.edu>
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.7
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Help: <mailto:9fans-request@cse.psu.edu?subject=help>
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <http://lists.cse.psu.edu/archives/9fans/>
Date: Tue, 13 Nov 2001 15:28:37 -0800


> Brucee's implementation just patches the call to point to the
> correct destination.  You don't have to walk any machine code.
> The (modified) linker emits a known call instruction, and relocation
> information which says where it is and what symbol to patch
> it with.  Symbol lookup is done in a highly controlled way.

This is just for kernel drivers, right?  While plan9's non-support of dynamic
linking for arbitrary C programs works just fine, it doesn't seem to work so
well for languages that only load libraries at run time, such as python or
perl (or limbo?).  If the linker can write relocation information, would that
make it easier to write a dlopen()-like function?
--upas-xktegibywnghqeehkcijpvhtjw--