Subject: Re: Apparent DLL loader problems. --> Rusian roulette with ld
From: [email-masked] (Mike Stephenson)

25 Jan 1997 11:17:19 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Original-To: [email-masked] (wiljan)
Original-Cc: [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]> from "wiljan" at Jan 25, 97 09:28:55 am
X-Mailer: ELM [version 2.4 PL24]
Original-Sender: [email-masked]

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:     [email-masked]
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".