From: root AT jacob DOT remcomp DOT fr (root) Subject: Re: Apparent DLL loader problems. 23 Jan 1997 21:11:37 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: Content-Type: text Original-To: mike AT sni DOT ca Original-Cc: gnu-win32 AT cygnus DOT com In-Reply-To: <199701231325.FAA11360@mail.dms.sni.ca> from "Mike Stephenson" at Jan 23, 97 08:25:18 am Content-Length: 3559 Original-Sender: owner-gnu-win32 AT cygnus DOT com > > 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 "gnu-win32-request AT cygnus DOT com" with one line of text: "help".