From: root AT jacob DOT remcomp DOT fr (root) Subject: Nobody in the world understands Gnu's 'ld'. 25 Mar 1997 08:05:53 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: Content-Type: text Original-To: jqb AT netcom DOT com (Jim Balter) Original-Cc: gnu-win32 AT cygnus DOT com In-Reply-To: <33367A5B.7807@netcom.com> from "Jim Balter" at Mar 24, 97 04:58:03 am Original-Sender: owner-gnu-win32 AT cygnus DOT com Jim wrote: > > void (*xxx)() = GetFullPathName; > > int STDCALL > WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) > { > return 0; > } > > I've tracked this down, and have determined that it dies with a SIGSEGV > which doesn't get printed anywhere because cygwin.dll prints it to > STD_ERROR_HANDLE, which isn't valid. Clearly it should do better, > at the very least writing it to the strace output if that is a file, and > a [snip] > > The point at which it dies is the at the very beggining of main() > from libcmain.cc, when it calls GetModuleHandle. That call goes to a > jump instruction that goes > through an indirect pointer that appears to contain the wrong > address, since it is the address of some code. The jump uses the > content of that code as the "location" to go to, and so it > dies. Perhaps to someone who knows about Windows dll's and jump tables, > the problem here might be obvious, but I know nothing of those things. > But it sure looks like a serious screwup by ld. A dll call under windows (NT or 95) is just a jump through a table of pointers to functions. This table (called 'import table') is built by the linker. The linker builds this table by using an 'import library'. That library contains several small pieces of code and special sections that, when combined together with some pieces of code in the startup (the famous .idata$3 section) will build that import table in the executable. This is an extremely complex and error prone process, that costed me months of horrible work when I wrote the linker for my system. I was VERY happy when it was over... Gnu's linker: A NIGHTMARE! ------------------------- Since several months people here report that Cygnus's linker is flawed. I think that it is just plain that Cygnus doesn't have the know-how to repair it, since Steve Chamberlain, the guy that wrote most of it, hasn't posted anything here since ages and he was very active before. Before writing my linker, I studied gnu's linker code with the naive assumption that I could use it. After spending weeks and weeks trying to understand it, I gave up and wrote mine. There is only ONE person in the world that understands that code and he is called Steve Chamberlain. If Cygnus doesn't have him any more, users of gnu-win32 will have to live with a flawed linker for the rest of their lives. Just to give you an idea, ld is supposed to link an object file from sun's unix format with some code from windows 95 and with some code of hp Unix. Of course this is ridiculous and it will never work, but this is how 'ld' is designed: an incredible complexity that (to me) seems completely unwarranted. It has a full blown LANGUAGE (with lex+yacc parser/lexer!) that is supposed to recognize linker commands. Obviously nobody ever uses it, but to understand what the linker is doing you have to go through yet another layer of complexity. Then you have the 'BFD' format, that is supposed to be an universal binary format designed by GNU that will abstract the binary format of all machines in the western world into ONE format. Obviously it doesn't work, but then you have not only to understand what binary format you have in windows (what is difficult enough) but you have to understand BFD too. And then you have the macro-sickness... You read: a = foobar(b->field); Well, where is foobar? Nowhere. It is a macro that will be expanded into an index into a table using b. Mmmm. This table is actually an table of tables. MMMMMMMMMMM. OK let's go on. In that table of tables you have a field that is a table of functions. GOD! WHATS THIS!!! But let's go on. That table of functions is indexed by that b->field to jump into ??? IT DEPENDS OF THE RUNTIME CONDITIONS. Of course! You can at the linker command line change the output format remember? You can link your windows object files to give a SUN OS executable isn't that FUN??? And to crown this beatiful construction there is NO DOCUMENTATION whatsoever about anything I have told you in this message. I inferred this from reading THE C CODE!!! Not surprisingly, Cygnus is stuck with a linker that nobody in the world understands... except Steve of course. But I think *even he* has problems to know what the hell is going on in there... That is why this linker can't even recognize MSVC object code format and use the MSVC .LIBs. Because nobody in the world is able to modify it. Of course we do not need compatibility with SUN or HP Unix under Windows 95. We would need MSVC compatibility. But to do that we would have to find somebody that understands 'ld'... I think that anybody using 'ld' is living very dangerously... -- 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".