This is the mail archive of the
mailing list for the Cygwin project.
Re: Creating a dll in cygwin for use with jni without -mno-cygwin
- From: Brian Dessent <brian at dessent dot net>
- To: cygwin at cygwin dot com
- Date: Wed, 08 Aug 2007 14:33:25 -0700
- Subject: Re: Creating a dll in cygwin for use with jni without -mno-cygwin
- References: <email@example.com> <46BA2D27.ADF36363@dessent.net>
- Reply-to: cygwin at cygwin dot com
Brian Dessent wrote:
> [...] your own initialization procedure that
> saves a copy of the bottom 4k, initializes Cygwin, and then restores the
> saved parts.
Just to be clear, I don't mean that it should initialize Cygwin and then
restore those parts of the stack.
To put it differently, when Cygwin initializes it expects to have free
reign of the bottom X bytes of the stack for its own use. You can
accomplish this two ways:
The designed way - have code that runs very early in the sequence of
process initialization that simply allocates these bytes on the stack
like a standard C auto variable, and since the stack is nearly empty
they will be at the bottom. This is what the Cygwin startup code
(crt0.o) does when you run a Cygwin binary, and how it is designed to
The "fake it" way - Assume that you want to load the Cygwin DLL
dynamically at runtime, and the stack has already been robustly
allocated/populated by whatever application is already running. You
have no control over the bottom X bytes, so you're kind of screwed. The
best you can hope to do is make a copy of those X bytes, then initialize
Cygwin (which now "owns" that area and will overwrite whatever's there
with its own data) and hope that the control flow of the application is
such that you will be able to unload the Cygwin DLL and restore those
saved bytes before program flow reaches a point where the stack gets
unwound down to that earliest frame.
If you don't take care of the deinitialization and restoration part then
everything will seem right but your application will probably crash and
die horribly when it terminates.
Obviously the key here is that you need to run this initialization code
as early in the process init as possible. If I recall right the cygload
code tries to do this right at the beginning of main() and at that point
there is only a small amount of data at the bottom of the stack to
save/restore, which also means the best chances of that data not being
referenced/used before it is restored.
[ X is sizeof(_cygtls) which has traditionally been less than 4K so 4K
is a nice round number but the current cygload actually uses 32k for a
safety margin, so the docs should be updated. ]
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html