X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:references:in-reply-to:subject:date
	:message-id:mime-version:content-type:content-transfer-encoding;
	 q=dns; s=default; b=FWZnBQPuLRWsU8xRW3RmeNKUu+FsPt8cfpN9BituScr
	q7/A7Gdj1X8CLl79nt6AHTxNRcfFqaRNfUaKKeSgEDeenkz4Ww5KWhpB8YBJFBh/
	777TJAP97kep90VFOevVVy2xcGE3VGbdqBWjQ5jcF7oooUrzeMSyF89Kbg8q8CY4
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:references:in-reply-to:subject:date
	:message-id:mime-version:content-type:content-transfer-encoding;
	 s=default; bh=zKg1kNancH/ed4M4nZ0USd8qD4Q=; b=eoOaAxMSENZ3qq4+N
	EnqADr/ofiWAJ+AY0L3fjfGlXlfKquXOAuugneJz4WObaD+ckCqMRzD1C3KtYTvu
	CEaO96iBulyjB+XsUP4qvS1aUA5PPCF+FMTKgPGz8qs426wqCRPABBEfYaWkWImE
	neTe4zJV7E/6B8UIqa7qhJ8WWM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_VIA_APNIC,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1
From: Fedin Pavel <p DOT fedin AT samsung DOT com>
To: cygwin AT cygwin DOT com
References: <003401ce6b5d$f6ec87b0$e4c59710$%fedin AT samsung DOT com> <51BF7465 DOT 2030104 AT users DOT sourceforge DOT net> <001301ce6bf0$ea4904a0$bedb0de0$%fedin AT samsung DOT com> <20130618101706 DOT GB27405 AT calimero DOT vinschen DOT de>
In-reply-to: <20130618101706.GB27405@calimero.vinschen.de>
Subject: RE: Cross-compiling Linux kernel
Date: Tue, 18 Jun 2013 16:06:00 +0400
Message-id: <003901ce6c1c$332722d0$99756870$%fedin@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id r5IC6G7Y012417

 Hello!

 While waiting for the Big Thing to finish compiling, another crazy idea visited my damaged brain. ;-) I wonder if it has some practical value...

> That's not quite correct.  The problem is not utilizing the native NT
> functions to create a process image, the problem is that the Win32
> libraries like advapi32, msvcrt, etc, which are directly or indirectly
> loaded into a Cygwin process, are not capable to deal with a process
> clone situation.

 So, in another words, we can clone everything except several known libraries. What if we use this fact ?
 Since we can create process image manually, what if we clone everything except these libraries ? Then we do a thing similar to what we do now, we start the program from the beginning but tell it to follow "short path", attach missing libraries and jump to our fork().
 Potential advantages:
 1. clone'able DLLs (i assume that all Cygwin DLLs are cloneable) are guaranteed to get the same addresses.
 2. (1) creates smaller number of variants for Windows native libraries, so we have smaller chances to get different addresses for them.

 Even more, what stops us from completely manual process image layout ? This way we could guarantee the same addresses for all libraries.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple