This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: MUCH faster cygwin.dll was RE:Time and motion studies of gccand egcs and LCC


Thanks, I had never seen the MS doc you quoted below,
and I guess Geoff hadn't either ;^).

I tried your rebase command on B18 and on cooview dll
and it didn't work on either?
Mar 97 SDK rebase.exe
win95b
so I had to rebuild from source to get the image to 0x61000000,
but this makes even more sense as a base address to me, see the comments
from RON below.

...cdk/winsup/Makefile
LD_STUFF += --image-base 0x61000000

MIKEY:/usr/H-i386-cygwin32/bin$ rebase -b 0x61000000 -d cygwin.B18_dll_fix
REBASE: *** RelocateImage failed (cygwin.b18_dll_fix).  Image may be corrupted

REBASE: Total Size of mapping 0x00000000
REBASE: Range 0x61000000 -0x61000000
MIKEY:/usr/H-i386-cygwin32/bin$

B18 ld.exe never marks dll's as dll's and
B18 strip.exe removes the DLL bit from the characteristics field in the file
header, if it exists, so after stripping the .reloc section, use your favorite
binary editor to change the byte at 0x97 from

00 00 00 00 E0 00 0F 01 B0
to
00 00 00 00 E0 00 0F 21 B0

this will mark the image as a DLL and allow faster
unloading.

Unfortunately win95 still won't relocate dll's that try 
to load after cygwin.dll in this address space 
(at least on my system), so make sure
any dll's you build don't overlap whatever address space
you choose for cygwin.dll.

BPE Version 1.3              cygwin.B18_stripped_dll          (C) 1988 MSS Graz

COMMAND :                                              Rel. Position : 00000000

 ADDRESS    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F      ASCII
===============================================================================
00000000    4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00    MZ..............
00000010    B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00    ........@.......
00000020    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00000030    00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00    ................
00000040    0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68    ........!..L.!Th
00000050    69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F    is program canno
00000060    74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20    t be run in DOS
00000070    6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00    mode....$.......
00000080    50 45 00 00 4C 01 05 00 45 04 EB 34 00 00 00 00    PE..L...E..4....
>>>>>>    00000090    00 00 00 00 E0 00 0F 01 0B 01 02 37 00 34 04 00    ...........7.4..
000000A0    00 70 00 00 00 16 00 00 68 2C 01 00 00 10 00 00    .p......h,......
000000B0    00 50 04 00 00 00 00 10 00 10 00 00 00 02 00 00    .P..............
000000C0    04 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00    ................
000000D0    00 00 05 00 00 04 00 00 00 00 00 00 03 00 00 00    ................
000000E0    00 00 00 02 00 10 00 00 00 00 10 00 00 10 00 00    ................
000000F0    00 00 00 00 10 00 00 00 00 90 04 00 3C 46 00 00    ............<F..

On Tue, 17 Feb 1998 09:32:16 -0600, you wrote:

>>Read here: 
>>>>Geoff I would recommend using --image-base=0x78000000
>>>>for cygwin.dll same as MSVCRT.DLL which is relocatable
>>>>and should never be loaded in the same VM anyway.
>>>
>>>You can move the base yourself if you have MSVC's editbin program:
>>>
>>>	editbase /rebase:base=0x78000000 cygwin.dll
>>>
>>>Do this before you strip the .dll...
>>
>>IMO, this is not a good address to rebase cygwin into. You are correct that
>>it is used by msvcrt.dll. However, all applications which load cygwin.dll
>>load msvcrt.dll. You must realize that much of the operating system was

This is only true if you use winsock 2.

>>linked to msvcrt.dll. If you look check it out, you will see the following
>>dependency chain:
>>
>>cygwin.dll --> wsock32.dll --> ws2-32.dll --> msvcrt.dll
>>
>>I discovered that both DLLs were being used while using Jeffrey Richter's
>>liposuction32.exe on ls.exe. I did a little digging of my own to find the
>>source of this behavior.
>>
>>Therefore I would recommend using the following command to rebase cygwin.dll:
>>
>>rebase -b 0x61000000 -d cygwin.dll
>>
>>This will map cygwin.dll at the upper end of the 0x60000000-0x60FFFFFF range
>>in accordance with the recommendations from Microsoft. The MSDN Library's
>>description of the rebase program contains the following
>>A well-behaved application has its DLLs rebased so they each fall within a
>>unique range of the virtual address space. The system DLLs are currently
>>based in memory from 0x70000000 to 0x78000000 (0x68000000 to 0x78000000 on
>>MIPS). Therefore, you should base your DLLs from 0x60000000 to 0x68000000.
>>One possible scheme is to choose a base address based on the first letter of
>>the DLL name, as shown in the following table.
>>First Letter	Base Address	
>>A - C	0x60000000	
>>D - F	0x61000000	
>>G - I	0x62000000	
>>J - L	0x63000000	
>>M - O	0x64000000	
>>P - R	0x65000000	
>>S - U	0x66000000	
>>V - X	0x67000000	
>>Y - Z	0x68000000"
>>
>-
>For help on using this list (especially unsubscribing), send a message to
>"gnu-win32-request@cygnus.com" with one line of text: "help".


=====================================================
Linux a platform built by, and for users, standing on
the firm legs of reliability, and speed.

Microsoft Windows, a platform without a leg to stand on.

(jeffdbREMOVETHIS@netzone.com)
delete REMOVETHIS from the above to reply
         Mikey
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]