Subject: Re: Apparent DLL loader problems.
From: [email-masked] (root)

23 Jan 1997 21:11:37 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Content-Type: text
Original-To: [email-masked]
Original-Cc: [email-masked]
In-Reply-To: <[email-masked]> from "Mike Stephenson" at Jan 23, 97 08:25:18 am
Content-Length: 3559      
Original-Sender: [email-masked]

> 
> I have a problem...
>  
>         No, I actually have a *big* problem - specifically a problem when
> linking very large programs.
>  
>         First of all, for historical reasons, I'm unfortunately still using
> B14.  One of my hopes is that someone can tell me if B17.1 will solve the
> problem.  I'm also mixing a set of statically linked gcc .a libraries with
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> dlltool extractions of both system dlls and my own MSVC 4.1 built dlls.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What a soup man!

Here are some strategies you could follow:

1. use the command:
dumpbin /imports yourprogram.exe >ww

2. Look at that 'ww' file. Are the exports OK?

3. Relink in another order.

4 Goto 1

I suppose that you have 'dumpbin', since you have MSVC 4.1.

Another strategy:
1. Build a version that traps at a known location (say 'lstat').
2. Just before the call to lstat add
	_asm("int 3");
   That is a hard coded breakpoint. This is to be sure the program stops
   there.
3. Disassemble the next instructions under gdb.
   Is really a bad address over there?

This two strategies have one goal: proving that your working hypothesis that
the problem is due to a bad import address is really true. Debugging consists
in making hypothesis about the nature of the bug and proving them.

If both tests leads you to believe that there is indeed a bad address
at execution time,  please remember that:
1. ld will generate a bad executable if it finds MSVC's debugging information,
   at least in the earlier versions, and I do not think (or have heared) that
   that problem is corrected.
2. Explore that possibility: relink your MSVC's dlls WITHOUT any debug
   information in them. This is just another working hypothesis, since as they
   are dlls, they are dynamically linked, so ld's fault would be somehow
   strange...

If that fails try another strategy:
1. Reduce the size of your executable to see if the size is a problem:
   Convert as much of the executable to dlls as you can. This will reduce the
   size of the executable that ld has to link.
2. See if you find a size where your executable works.
If you find it, you know why your program crashes. Now you would have to
debug 'ld': this would mean that there is a buffer overrun when the size of
the executable is beyond a certain limit.

But there are MANY other possibilities that you should also consider: 
1. Are your calls to the dll functions OK? Are you sure there is no _stdcall
   functions in the dlls that are NOT declared _stdcall in your calling code?
   Because that would leave the stack in a mess, and you would have the same
   symptoms: the program would crash randomly... and not at the place of the
   faulty call but much later, probably when it executes a RET instruction...
2. Review the compilation options for building the MSVC dlls. Are they _cdecl
   by default? Are the structure alignment options compatible with gcc's? If
   you push a pointer to a structure (the 'stat' structure for instance) and
   the alignment of the two compilers are different you will corrupt the
   stack of the calling function...

Debugging is an exercise of the mind, like doing jigsaw puzzles or playing
chess. As we build more and more complex systems, the game becomes more and
more difficult but, that's the fun of it! Taming complexity.

Cheers
-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".