Subject: Re: MUCH faster cygwin dll
From: [email-masked]

20 Feb 1998 09:16:34 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
To: [email-masked]
Cc: [email-masked]

In gnu-win32 [email-masked] writes:

>Normally, for all windows programs, there exists a .reloc section in the
>executable, that tells the loader the relative location of all pointers in
>the image. Then, the loader can put the new dll anywhere in the addressing
>space of the vm it wants to load it in.

>It seems then that acknowledging that gnu's linker is broken you have returned
>to the 'solution' of moving your dlls around by yourself and replacing the
>system loader.

I don't know why people are saying that DLL relocation does not work.
It works fine for me.  I've run programs with several DLLs linked with
the default image base, and the loader relocates all but one of them
out of the way.  I did this routinely for several months, while
working on a project which ran on Windows built with cygwin32, before
I got tired of the relocation and fiddle with the image base to have
the DLLs load at different address.

Note that I'm not using the b18 linker.  I'm using a linker built from
the current development sources.  I don't know what the state of the
b18 linker is.

The development sources are publically available for anybody who is
willing to deal with problems themselves.  I believe that Mumit Khan's
releases include linker code based on snapshots that are newer than
b18.

Still, building a relocateable DLL is a pain.  You have to run the
linker three times and dlltool twice.  Fixing this would require
incorporating dlltool in the linker, as should have been done in the
first place.  This would mean making the Windows DLL support act like
the Unix shared library support.

Mikey earlier reported a problem with marking a DLL as a DLL.  I've
investigated the problem he reported, and it does not appear to be a
problem with the current linker.

>This will never work OK of course, but it is a better solution than nothing.
>If you say it like this in the list however, people will think that this is 
>                               *normal*
>imagine. That for loading a dll you have to tell the system the hexadecimal
>address of where you want it loaded. What a user friendly environment!!!!

My impression was that people were discussing the hex address more for
startup speed, by ensuring that all DLLs were at a different address
to avoid the time spent relocating them.

>This is an example of a bug that will never get fixed, as I said in this list
>almost a year ago. It has *never* worked for dlls and it will *never* do it.

>On March 25th 1997 I wrote to this list:
>Nobody in the world understands 'ld'. (in the subject line)

>Then I forecasted that this bug will never get fixed since Steve Chamberlain,
>the person that wrote the win32 part of 'ld' left cygnus.

>That was a year ago.

>It is true that Mr Taylor has fixed some (other) problems. But the dll bug is
>just too much, and people are confronted with bugs they can't understand nor
>handle.

This is so absurd that I'm kind of at a loss as to how to reply.  The
notion that it is possible for a program the size of the linker to
have a bug which can not be fixed is completely out of touch with any
reality I live in.  I'm particularly astounded that you, a
knowledgeable programmer, would make such a claim.

If you feel that you can not fix whatever bugs there may be in the
linker, that's OK.  Please don't tell me what I can't do, particularly
not on a public list.  I think that an examination of the publically
available binutils sources will show that my linker credentials are in
order.

Ian
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".