X-Spam-Check-By: sourceware.org
Message-ID: <46416B9E.71C3D2C3@dessent.net>
Date: Tue, 08 May 2007 23:35:10 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Please Help!! Calling Socket function in a dll file (that is created   using cygwin library), by a Microsoft Visual C++ program resulting in   infinite loop
References: <507150040705021415r750600a6oc6e24b339bf57143 AT mail DOT gmail DOT com> 	 <463909F9 DOT 6B33B9C7 AT dessent DOT net> <507150040705081919i1cbf7194y9672fc6a1b1601a2 AT mail DOT gmail DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
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

kalasad mailu wrote:

> I read the following from the how-cygtls-works.txt
> 
> "If you load cygwin1.dll dynamically from a non-cygwin application, it is
>   vital that the bottom CYGTLS_PADSIZE bytes of the stack are not in use
>   before you call cygwin_dll_init()"
> 
> How do I make sure bottom CYGTLS_PADSIZE bytes of the stack are not in use
> before you call cygwin_dll_init()"
> 
> I could not find any information at: winsup/testsuite/cygload

The files cygload.cc and cygload.h are in winsup/testsuite/winsup.api. 
They show a pretty complete example of how to dynamically load the DLL
and deal with the stack and signals.  There are several general ways to
make sure the bottom of the stack contains the scratch space, in roughly
ascending order of ease/quality:

- Reserve the space at the earliest possibility in the CRT startup
objects (this is how native Cygwin apps do it, or rather how they don't
have to worry about it)

- Change the entry point to your custom routine that saves the state of
whatever is at the bottom of the stack (hopefully nothing or close to
nothing, since this is very early in the init sequence), replaces the
bottom of the stack with your scratch/padding, calls the stock entry
point, and after that returns restores the previous contents at the
bottom of the stack.  This is how cygload does it, using the neat
feature of C++ ctors and dtors to take care of some of the housekeeping.

- If you can't do either of the above then you roughly do the same thing
but at a later point in execution, e.g. by wrapping main() (or WinMain
or DllMain or ....) or even by initializing/deinitialzing your scratch
space as the first and last things in main(), etc.  (Look in CVS at
older versions of cygload which did it with less finesse this way.)

It's all still the same concept though, just with various amounts of
already existing stuff (from zero to lots) at the base of the stack when
your routine gets called.

Note about terminology, the scratch space needs to exist at the bottom
of the stack in logical terms, i.e. the very first n bytes pushed on the
stack.  But because on x86 the stack grows down this scratch space will
be at the numerically highest address.  Don't get confused though, it
all essentially amounts to just being the first to allocate a large auto
char[] array; or faking it by manipulating the stack pointer directly if
you aren't the first in line to touch the stack, and saving the state of
whatever was there before you so you can restore it before ceding
control back to whoever called you.

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/