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 >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.