Re: RFC: Cygwin 64 bit?

[Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>]

On 29/06/2011 2:56 AM, Corinna Vinschen wrote:
> On Jun 28 23:45, Thomas Wolff wrote:
> > Am 28.06.2011 23:36, schrieb Ryan Johnson:
> > > > On Jun 28 22:36, Thomas Wolff wrote:
> > > > > Can't cygwin compilation ensure that the cygwin1.dll is always
> > > > > loaded first so it could take care of this (if only by then adding
> > > > > to the path)?
> > > > > (I guess the answer may be no because Windows is juggling with
> > > > > the DLLs...)
> > > > [...]
> > > The answer is definitely "no." Windows can map dlls in any order
> > > it pleases, and is only semi-required to initialize them in
> > > dependency order (because dlls are often circular dependent
> > > anyway). In particular, dlls which suffer base address collisions
> > > tend to be loaded before cygwin1.dll
> > Last feable attempt: So why does cygwin have to let Windows load the
> > DLLs at all? Couldn't the programs just have a stub that uses a
> > dedicated version of dlopen for dynamic linking?
> In theory, yes.  Every libfoo.dll.a would have to point back to Cygwin
> and Cygwin could call LoadLibrary/GetProcAddress so that there's no
> explicit load-time linking anymore as far as Cywin DLLs are concerned.
> That requires support by gcc/binutils/libtool(?) when building shared
> libs, though.
Hmm. Given the problems we've had with fork() and statically linked 
dlls, the issue of cyg64/bin64, and now this, maybe we should take 
advantage of the fact that we'll be mucking around with gcc/binutils 
anyway and do what Thomas suggests? Technically, it's only necessary to 
do this for dlls directly linked against the final executable -- 
anything dynamically loaded we could extract the dependencies for and 
preload ourselves (we already do this at fork, though that job is easier 
because all the dll images we'll need are already mapped).

We (= gcc/binutils) would have to emit the proper thunks and arrange for 
them to be initialized, or else gcc would have to silently emit calls to 
function pointers everywhere the dll was used, no? The former seems 
cleaner, though it would be nice if we had a way to hook into the 
functions Windows uses to initialize thunks (is it done lazily like I 
think it is?).

Also, dll loading (unloading) is verboten inside the dll's ctor (dtor) 
because they execute while holding the loader lock. We'd have to add a 
static init/destruct routine instead, though I guess that's not so 
terrible.

Finally, such a change would make cygcheck rather less than useful. 
Maybe we'd need a special section containing the names of all 
"cygwin-static" dlls which cygcheck knew how to read? Or does cygcheck 
actually execute the process far enough to see what it loads?

Caveat: I don't know enough about gcc/binutils to make the above magic 
happen, though given a section listing cygwin-static dependencies 
(essentially like the existing static deps section) I could probably 
make cygcheck do the right thing and/or help some with the cygwin-static 
load process.

Ryan