Mail Archives: cygwin-developers/2001/06/09/19:46:27
----- Original Message -----
From: "Matt" <matt AT use DOT net>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: <cygwin-developers AT sourceware DOT cygnus DOT com>
Sent: Sunday, June 10, 2001 3:41 AM
Subject: Re: dll base address
> On Sat, 9 Jun 2001, Robert Collins wrote:
>
> > As you can see, cygwin1.dll has been loaded at 02561000. It seems to
me
> > that if __cygwin_user_data is a non-relocatble variable, that we
should
> > mark cygwin1.dll as non-relocatable.
>
> The newest Purify supposedly works on COFF symbols, which would mean
it
> *might* work on Cygwin/gcc generated executables and DLLs. Purify
requires
> that the DLLs be relocatable (have a .reloc section) for it to really
> work. Making cygwin1.dll non-relocatable would certainly increate
start-up
> time, but would eliminate the possibility of using Purify.
>
> The last time I tried using Purify 2001 (2001A is now the latest), I
> thought it said that cygwin1.dll didn't have a .reloc section.. I'll
try
> it again this weekend with Purify 2001A.
>
A detailed example is this:
program 1 (bash) loads. cygwin is located at 0x61000000.
bash calls spawn(). The cygwin spawn_info struct is located at
0x6109330a.
program 2 (testprogram) linked with a dll that resides at 0x610c1000 is
started by cygwin, in paused mode.
Cygwin then writes into it's address space the spawn_info details. _AT
0x6109330a._
However, 0x6109330a is invalid for that process, because it's loaded
cygwin1.dll at 0x025651000.
cygwin in the bash process starts the testprogram process running, the
dcrt1_0 function starts at dll_attach time, finds the spawn info data
pointer, but cannot read the data, and then starts reading semi-random
address' - which is a bad thing to do in dll_entry!:}
From that you can infer that the reason the programs work from gdb,
strace and cmd.exe is that they are not being spawn()ed - there's no
sync_info to find and read.
Rob
- Raw text -