From: colin AT fu DOT is DOT saga-u DOT ac DOT jp (Colin Peters) Subject: RE: Symify-type core dump stack explainer? 7 Oct 1998 17:59:46 -0700 Message-ID: <003501bdf19c$328aeec0$fa173185.cygnus.gnu-win32@gbird0.fu.is.saga-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: "Adam Chlipala" Cc: "GNU-win32" Adam Chlipala wrote: >Is there a utility that I can use to add function names to core dump >stack tracebacks? I've gotten GLUT and OpenGL to work with CygWin32, >except for the small problems that all GL drawing functions besides >glClear() crash with core dumps or standard Win32 dialog box crashes. >Perhaps this has been tried and CygWin32 can't work well with >opengl32.dll and glut32.dll compiled in MSVC++; I don't know. If this >is the case, I would appreciate a tip-off so that I don't waste my >time. If not, I would like information on how to figure out what the >problem is. On a side note, I had to modify the GL and GLUT header >files to remove all APIENTRY's.. could this be the cause? Seems >unlikely. No idea about the utility for function names (at worst you could use nm and look up the address of the function by hand-- ugh), however I do think that removing the APIENTRY might be causing your problems. Let me make a couple of guesses: 1. glClear is the only GL function you have tried (or exists) which takes no arguments. 2. You had to remove APIENTRY to stop the linker complaining about missing functions like glFoo AT 8 and such OR to stop complaints at runtime that your programs needed a function glBar AT 16 not exported by DLL opengl32.dll. If these are right then I strongly suspect that APIENTRY defines the calling convention for functions as "standard call" (or stdcall, or PASCAL, or even WINAPI). Standard call calling conventions make the called function remove arguments from the stack. In standard C the calling function removes the arguments from the stack. If you get a mismatch between caller and callee concerning the convention used the stack will be corrupted and on very short order the program will crash. The only time you might be safe is if the called function takes no arguments at all. Just checking though, and glClear appears to take an argument... hmm. Anyway, I might still be right :). The .def file I have for opengl32 looks like this: EXPORTS DllInitialize AT 12 glAccum AT 8 glAlphaFunc AT 8 glBegin AT 4 .... But if I look at the exports from opengl32.dll with impdef I get EXPORTS DllInitialize .... glAccum glAlphaFunc .... glBegin .... This says to me I should use the first .def file (with the @nn) and build the import library like this: dlltool --dllname opengl32.dll --def opengl32.def --output-lib libopengl32.a -k The -k removes the @nn from the exported names (but not from the internal names, because gcc generates the @nn for any stdcall function). If all I had was the output of impdef (or some other such tool) I would be forced to add the @nn to the function names. One way to figure out what values are needed is to try a link a program using a given function and use the number reported in the linker error message (e.g. unresolved external glFoo AT 8 means add @8 to the function glFoo in the .def file). Hope this helps, Colin. - Colin Peters - colin at fu.is.saga-u.ac.jp - http://www.geocities.com/Tokyo/Towers/6162/index.html - Go not to usenet for counsel, for it will say both - 'yes' and 'no' and 'try another newsgroup'. - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".