This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Symify-type core dump stack explainer?


Adam Chlipala <psion@tpu.org> 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@8 and such OR to stop complaints at runtime that your
programs needed a function glBar@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@12
glAccum@8
glAlphaFunc@8
glBegin@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@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@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]