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 work. 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. ] Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
