Re: [Mingw-users] DLL image basing, in depth Q

[Paul S. <pa...@is...>]

Hello Soren,

Soren Andersen <so...@wo...> wrote on Wednesday, December 13, 2000:

SA> Hello List-MinGW,

SA> Through many trials and errors I've been learning about making DLLs
SA> using MinGW and I've focused on software (typically gnu or similarly-
SA> licensed Open Source software written in C) that comprises part of a
SA> typical Linux installation (libjpeg, libpng, etc.) My OS is WinNT4.

SA> Can readers explain to me please about strategies for dealing with image
SA> basing of relocatable DLLs? I understand that there is a default base
SA> address that, absent the user giving another to gcc explicitly, will be used
SA> at DLL-making time. If one builds multiple libs and all use that same base
SA> address, I think the OS has to relocate the DLL when it's called by a
SA> linked application, to another free address, if the given base is already
SA> "occupied"? If so, does this slow down the loading and execution of the
SA> object code needed in the DLL?

    Loading - yes, execution - no (modulo all the boring on demand
optimizations).

SA> If so, how much;

    Of course, not noticable for average human ;-)

SA>  and are there any other
SA> side-effects (penalties) of this extra relocation step?

    (Partial) non-sharability. IMHO, this is more serious than 20ms
delay.

SA> If the above describes something that IS a concern -- and I believe it is,
SA> for reasons that aren't rigorous but more of a guess and a surmise based
SA> on trying to grasp what I've read here and around in the past -- then
SA> how do users on this List (the "experts") go about telling gcc what to use
SA> for a base address?

    They tell --enable-auto-image-base. In new mingw ld, this is
default (in fact, it seems to be turned off in current beta, that's
bug; oh well, it needs to be tested how it works with explicit image
base). auto-image-base does its work quite good. For example, I had
one large C++ dll which is pain in the neck to link, so I split it
into 9 small ones. Now I have:

E:\projects\OA-work\test\widgets>ldd -v testwidgets.exe
        ntdll.dll => E:\WINNT\System32\ntdll.dll (0x77f80000)
        liboa_edit_cmd.dll => e:\usr\local\bin\liboa_edit_cmd.dll (0x6bf40000)
        liboa_gem.dll => e:\usr\local\bin\liboa_gem.dll (0x604c0000)
        liboa_object.dll => e:\usr\local\bin\liboa_object.dll (0x65140000)
        liboa_utils.dll => e:\usr\local\bin\liboa_utils.dll (0x6a9c0000)
        KERNEL32.dll => E:\WINNT\system32\KERNEL32.dll (0x77e80000)
        msvcrt.dll => E:\WINNT\system32\msvcrt.dll (0x78000000)
        liboa_opal.dll => e:\usr\local\bin\liboa_opal.dll (0x67440000)
        liboa_widgets.dll => e:\usr\local\bin\liboa_widgets.dll (0x6abc0000)
        liboa_anim.dll => e:\usr\local\bin\liboa_anim.dll (0x6d280000)
        liboa_inter.dll => e:\usr\local\bin\liboa_inter.dll (0x69b80000)
        GDI32.dll => E:\WINNT\system32\GDI32.dll (0x77f40000)
        USER32.DLL => E:\WINNT\system32\USER32.DLL (0x77e10000)
        WINMM.DLL => E:\WINNT\System32\WINMM.DLL (0x77520000)
        ADVAPI32.DLL => E:\WINNT\system32\ADVAPI32.DLL (0x77db0000)
        RPCRT4.DLL => E:\WINNT\system32\RPCRT4.DLL (0x77d40000)

SA> Specifically, starting at the default or user-set base
SA> address, what determined how high into the memory addresses
SA> (counting upwards) the DLL loads? Is there a consistent predictable
SA> relationship between the size of the DLL executable object file on disk (in
SA> bytes) and the amount of memory required to load it -- a one-to-one
SA> correspondence? Is there any additional margin or overhead, perhaps?

    This all is deterministic and non-documented, of course.

SA> The reason I ask is that I have been looking at the source for X11R6.4
SA> and I see what the bright folks at Cygwin did to port various pieces of X
SA> to win32. In one Imake Makefile there is some code that accesses a
SA> temporary "counter" file on the local filesystem (in /tmp) and uses
SA> whatever is in there as the starting point for setting the base address.
SA> There's some very fancy shell scripting going on that instance (in that
SA> Makefile), however, and I didn't understand entirely the syntax and flow
SA> of what i was seeing -- just took it as a vague clue. And the comments to
SA> the code say that they are building every DLL in the X global package
SA> based to a different, unique address. So clearly they think it important.

    Yep, that's good. If they decreased default stack reserve for ld, that
would be good, too. Every new thread uses that value, so with current
32mb some little 30 threads will render half on virtual space
unusable.

SA>    Thanks for any help you can give me,
SA>       soren andersen

SA> P.S. Is anyone on this List actually running a minGW-built X on a win32
SA> system? If so, what X window manager do you prefer? <- slightly OT

    I don't know what mingw-built X you mean, but I downloaded
win32-x11 binaries (so far it builds with msvc, IIRC) and fetched its
sources. It comes without window manager, does it? I'm afraid breeding
native X with cygwin clients may take the same time as porting in the
first place. O, btw, I would prefer GNOME ;-)

--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135