From mboxrd@z Thu Jan 1 00:00:00 1970 From: Colin Peters To: "'Gunther Ebert'" Cc: "gnu-win32@cygnus.com" Subject: RE: .def files for stdcall functions (was: linking problems with the minimalist version) Date: Wed, 17 Sep 1997 00:03:00 -0000 Message-id: <01BCC380.AA4AF2C0@gbird0> X-SW-Source: 1997-09/msg00319.html Gunther Ebert[SMTP:gunther.ebert@ixos-leipzig.de] wrote: >Colin Peters wrote: >> My beef with all this is: why does GCC do it this way at all? What purpose >> does the @NN serve? After all, GCC knows how to generate the correct >> function call given a prototype, it *generates* the @NN, so it doesn't >> need it to know what to do. > [snip] This (enforcing agreement between caller and callee about the state of the stack, which would be very painful to debug otherwise) is, indeed, a good reason and I stand enlightened. What we have here is an inadequacy of tools. True, pedump can be used to pick the names out of an import library generated by MSVC (which are mangled in the same way), and in fact I think the tool I mentioned earlier (dumpexts) is a version of pedump made to perform exactly this operation. It remains true, however, that sometimes one does not have a .def or .lib file, like, for example, when you are generating the DLL yourself. In these cases we are stuck going back and figuring out by hand (or via repeated experiences with unresolved externals) the number of bytes on the stack to add to the name. In this situation it would be nice to be able to either: 1) Get GCC (or another tool) to generate the .def file (or even better the .a file), based on the prototypes (something like the __dll... keywords in MSVC). The intelligence is there in the code, more or less. Someone just needs to put it together. 2) Get GCC to not generate the @NN for stdcall function calls, probably through a command line switch, in which case we could use dlltool and the plain function names in a .def file (which, while still painful, is a lot easier than trying to figure out the stack sizes by hand). It would also be nice to get all of these different functions to do with dynamic linking integrated somehow. Just out of curiosity, how different is the way shared libraries are done under UNIX? >1) If there are any problems with wrong or missing prototypes for > _stdcall functions the linker would complain with an 'unresolved external' > message. You will never get a program with wrong function calls. >2) In order to get all Win32 API functions working there must not be any > function prototype containing parameters which are less than 4 bytes > in size, even if the parameters are actually WORD or CHAR or BYTE or > something else. Please check your windows header files if they > contain prototypes with WORD or CHAR parameters. Replace WORD > or CHAR parameters by DWORD parameters. Isn't there an option to force stack alignment? If there is then shouldn't it be on by default, at least for -mwindows programs? I admit I can't find it in the docs right now... sounds like a candidate for a function attribute. >In fact, MSVC mangles _stdcall names in the same manner as Cygnus gcc does. As pointed out by another, this is another good reason. I don't really expect much to be done about this, it's just a rant. Still maybe someone with the appropriate tools at hand will decide to make the effort. I can always hope... Colin. -- Colin Peters - Saga Univ. Dept. of Information Science -- colin@bird.fu.is.saga-u.ac.jp - finger for PGP public key -- http://www.fu.is.saga-u.ac.jp/~colin/index.html -- http://www.geocities.com/Tokyo/Towers/6162/ - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request@cygnus.com" with one line of text: "help".