From: mike AT sni DOT ca (Mike Stephenson)
Subject: Re: Apparent DLL loader problems. --> Rusian roulette with ld
25 Jan 1997 11:17:19 -0800
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <199701251807.KAA01654.cygnus.gnu-win32@mail.dms.sni.ca>
Reply-To: mike AT sni DOT ca
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Original-To: W DOT Derks AT nl DOT cis DOT philips DOT com (wiljan)
Original-Cc: report AT gnat DOT com, gnu-win32 AT cygnus DOT com, Pascal DOT Obry AT der DOT edfgdf DOT fr
In-Reply-To: <199701250834.JAA13570@nl.cis.philips.com> from "wiljan" at Jan 25, 97 09:28:55 am
X-Mailer: ELM [version 2.4 PL24]
Original-Sender: owner-gnu-win32 AT cygnus DOT com

wiljan writes:
> 
> Mike wrote:
> 
> >         From the debugger output, it looks like the indirection table
> > used by some of the system calls (e.g. lstat, setjmp) are not being
> > properly initialized when cygwin.dll is loaded.  They seem to be retaining
> > data  that they had on program start (probably the relative address of the
> > routines inside the dlls, but I don't know).
> >  
> >         The exact point at which the program dies changes, depending on the
> > order of linkage of the exact same modules.  For example, if you link with
> > one order, setjmp fails by jumping out to an invalid address, relink in a
> > different order and lstat does the same thing.
> 
> I have exactly the same problem.
> I have a call to getsystemtime in my executable. When checking
> the linkmap, ld takes the right things from libkernel32.a
> But when the image is loaded the call to getsystemtime does not
> work because the indirect jump to it is WRONG. I checked this with gdb.
> I have checked my executables with
>    dumpbin/imports
> For a bad executable the routine getsystemtime is simply missing from
> this import list and I am 100% sure that I use it.
> This will cause the program to be loaded incorrectly.
> 
> Besides this I have also seen that linking order can make a big difference
> in the size of the .text section of the executable. Sometimes it is
> simple 3 times a big (instead about 8000 18000 hex).
> This also indicates that ld does something wrong when generating the .exe
> 
> It only seems to happen with larger programs.
> In general it means that one can not trust images generated by ld.
> The errors can apear at any state of a project, by simply adding some code.
> 
	It is good to at least know that it isn't something that I've
done wrong :-)

	I spent yesterday making absolutely sure that there was no 
debugging information in any of the DLL's that I created.  I repeated
my tests and got the exact same results.  I'm going to start tearing
apart the executables on Monday looking anything that I can find that
looks out of the ordinary.
> 
> Who can help me with this problem ??
> 
	Sounds like a job for someone who really knows the guts of
ld and dlltool.
> 
> I am using 17.1
> 
	But I'd bet that the source base for ld is the same in both
B14 and B17.1 - I don't think that there has been a new release of gcc
in the interim.  I've started moving to B17.1 anyway.

						Mike

Mail:	Siemens Nixdorf 		Phone:	(905) 819-5944
	Document Management Systems	FAX:	      819-5949
	2185 Derry Rd. West
	Mississauga, Ontario
	Canada   M3C 3L8		INTERNET:     mike AT sni DOT ca
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".