Mail Archives: cygwin/2006/02/21/11:10:34
"Dill, Jens (END-CHI)" wrote:
> I have found Microsoft's Platform SDK, and have used the VaDump utility
> to find out where all the DLL's are loaded. Here is what it says about
> my app (sorted into ascending order of memory address):
FYI, to check the ImageBase of a given DLL you can just use objdump,
e.g.:
objdump -p /bin/cygwin1.dll | \
perl -ne 'print "$1\n" if /ImageBase\s+(\S+)/'
To see the memory layout of a running process you can use Process
Explorer from sysinternals.com which shows you in realtime the image
base and the relocated (actual) address where each DLL ended up loading.
> (1) Force the CygWin DLL to load first, so that it bumps the
> Oracle DLLs and not vice versa. (I'd need a reliable way
> to ensure this, not just a chance dependency on how the
> loader currently operates).
I'm not sure that this is possible. It's kind of the heart of the "fork
error: unable to remap" problem since the memory layout for dynamically
loaded modules that haven't been rebased seems to be indeterminite.
Thus the creation of the rebaseall tool and assigning unique addresses
to all DLLs so that the layout is invariant.
I think your best bet would be to keep poking at rebase to see if you
can't actually rebase the Oracle DLLs.
> (2) Rebase the CygWin DLL so that it loads by default into a
> space not used in either memory map (I'd need help in
> choosing such a space). I've tried both Microsoft's
> rebase and CygWin's rebase, but the documentation for both
> is scanty (how is the -b argument to be formatted -- a hex
> number with 0x in front or without?), and the error messages
> I get in response are not helpful (error 6?).
There's no need to rebase cygwin1.dll. You can just change the base
address assigned to it when it's created. This is defined in cygwin.def
which is a generated file from cygwin.din.
And for examples of how the rebase arguments are formatted, look at the
source to rebaseall (which is just a bourne script.)
> (3) Fix CygWin so that it does not care if the DLL is relocated
> during a process swap. The offending component is something
> called "cygheap". I can infer that this is a space in which
> CygWin processes store some kind of state information that
> must (a) survive a process swap, and (b) still be addressable
> by pointers that can't be relocated. Surely there's a better
> way to do this, but I'd need weeks of study to find one. I
> can apparently (according to the source code (dcrt0.cc, line
> 1177) disable the whole thing by setting the CYGWIN_MISMATCH_OK
> environment variable, but I have so far found no documentation
> of the risks and implications of doing so.
The problem here is that in order to emulate fork(), the Cygwin DLL
needs to be able to recreate a given memory layout when spawning a copy
of the process. Without any OS assistance this is kind of an ugly task,
and it breaks if things radically change from parent -> child. It does
have some capability to do fixups to move stuff around but I'm not sure
it can cope with the Cygwin DLL itself loading in a different region.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -