From:	cgf AT bbc DOT com (Christopher Faylor)
Subject:	Re: Optimizing memset/memcpy/strcpy/etc.
16 Feb 1998 22:00:06 -0800 :
Message-ID:	<199802170528.AAA05925.cygnus.cygwin32.developers@hardy.bbc.com>
Reply-To:	cygwin32-developers AT cygnus DOT com
To:	ian AT cygnus DOT com
Cc:	cygwin32-developers AT cygnus DOT com

>From: Ian Lance Taylor <ian AT cygnus DOT com>
>Date: Tue, 17 Feb 1998 00:09:06 -0500
>
>Some of the posts on the gnu-win32 list have implied that Windows
>always relocates DLLs if they have relocation information.  I would
>hope that that is not true--if the DLL is loaded at the image address,
>it should not be relocated.  Does anybody know exactly what Windows
>does?  Perhaps there is something incorrect about the DLLs which
>dlltool generates, which is leading Windows to always relocate them.
>Or perhaps the messages on the mailing list have been wrong.

I did try changing the base address for cygwin and removing the relocation
entries using the method that jeffdb AT netzone DOT com (?) proposed.  I thought
I noticed a speed improvement but I can't say for sure.  I'm building the
latest snapshot now without removing this information so I should know
better soon.

He also mentioned that ld wasn't putting information in the .dll that
somehow indicated to windows that a .dll was a .dll (I'm sure you saw
this), causing cygwin.dll to be loaded at a fixed address:

>BTW remaking cygwin.dll with the following patch to ld.exe does
>NOT exhibit this behavior, relocatable dll's get relocated like they
>are supposed to. (actually according to gdb cygwin.dll gets 
>relocated first then the next one at that address and so on)
>
>--- ld/emultempl/pe.em     1997/12/15 16:07:24     1.1
>+++ ld/emultempl/pe.em     1998/02/14 16:33:45
>@@ -142,6 +142,7 @@
>   D(MajorSubsystemVersion,"__major_subsystem_version__", 4),
>   D(MinorSubsystemVersion,"__minor_subsystem_version__", 0),
>   D(Subsystem,"__subsystem__", 3),
>+  D(DllCharacteristics,"__dll__", 0),
>   D(SizeOfStackReserve,"__size_of_stack_reserve__", 0x2000000),
>   D(SizeOfStackCommit,"__size_of_stack_commit__", 0x1000),
>   D(SizeOfHeapReserve,"__size_of_heap_reserve__", 0x100000),

So, if Jeff is to be believed, cygwin was never actually being relocated
anyway.

Anyway, I also experimented with changing a few common routines from functions
into macros with no discernible effect.  I agree that a profiler would be
invaluable in figuring out how to speed up cygwin.

- Raw text -