Re: libtcl8.5.dll collides with Cygwin DLL by default

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Mar  7 17:57, Yaakov (Cygwin/X) wrote:
> On 2012-03-07 04:42, Corinna Vinschen wrote:
> >the default base address of libtcl8.5.dll collides with the address
> >space of the Cygwin DLL.  Sure, we can't quite avoid DLL collisions,
> >but this kind of collision results with high probability in a crash,
> >rather than a collision detection message from Cygwin.
> 
> Tcl does not use any special linker options, so this is a result of
> --enable-auto-image-base, which gcc has been using by default for
> some time.  See ld/emultempl/pe.em:
> 
> static unsigned long
> compute_dll_image_base (const char *ofile)
> {
>   unsigned long hash = strhash (ofile);
>   return 0x61300000 + ((hash << 16) & 0x0FFC0000);
> }
> 
> This would be based on an assumption that cygwin1.dll's ImageBase is
> 0x6100000 and its SizeOfImage 0x00300000.  That was correct through
> 1.7.7, but since then:
> 
> 1.7.8:   00350000
> 1.7.9:   00450000
> 1.7.10:  00470000
> 1.7.11:  00480000
> 
> I'm not sure what is causing this continuous change, but the

Well, changes in the DLL are causing this change :)

But seriously, the most important change was probably raising the size
of the cygheap area from 512K to 1 Meg (1.7.8) to 2 Megs (1.7.9).
1.7.10 added a lot of functionality so the text segment became
considerably bigger.

> now-incorrect assumption is the real problem: any DLL with a
> strhash() within a certain range will have the same issue.  So
> unless there is a way to get our SizeOfImage back down to
> 0x00300000, the correct fix needs to be there (keeping in mind
> future growth).

The assumption that the Cygwin DLL has a given size and will never
change is flawed.  How are we supposed to add new functionality if the
DLL has to stick at a certain size?  And even using another GCC can
easily change the size of the DLL, given changes in code generation.

> >Do you think it's ok if you create a new tcl package with another
> >default base address for libtcl8.5.dll?
> 
> With a patched binutils, I suppose.  But this begs the question, how
> many other DLLs are affected?

Hmm.  So what we desperately need is a more intelligent rebase algorithm
which allows to call rebase as part of the setup postinstall.

The problem is this:  Right now rebase does not handle DLLs gracefully,
which are in use.  Those DLLs are blocked and cannot be changed.  What
rebase does is to remove these blocked DLLs from its list and later from
the database.  Therefore it's too dangerous to use rebase in postinstall
at the moment.

What rebase *should* do is to mark the DLLs as blocked, and keep them in
the list together with their current address and size, so it can arrange
the addresses of the other DLLs, taking the blocked address space into
account, just like it does with the Cygwin DLL.  And of course, the DLL
should not be removed from the database.

Is there anybody here who would like to tackle this?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat