This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: Stack traces in own program in cygwin

Bas Vodde wrote:

> Thanks for the reply. Where can I find the cygwin code that unwinds the
> stack? I might have a look at it anyway :)

Look at class stack_info in winsup/cygwin/  It's pretty
simplistic, and I'm pretty sure it will be rendered totally ineffective
by -fomit-frame-pointer.

> The problem I have with dbghelp is not whether the DLL is available, but
> whether the WinSDK is... It would require a header file (which is
> possible to fake) and a .lib. I'm not sure how to call the dbghelp calls
> without linking to the library. (though this should be possible, I just
> don't know how and where to find info about how to do it). If you for an
> idea about this, then that also could help me forward :)

You can use LoadLibrary/GetProcAddress, which removes the need for the
SDK and import lib/header at build time, assuming that you recreate the
appropriate types in one of your headers.  It also provides your program
an opportunity to do graceful degredation if something goes wrong, e.g.
the user is running 9x/ME, or they have a version of the dll that's too
old, or the library has been removed, or whatever.  The disadvantage
here is that for every function you use you first have to declare a
function pointer with the correct return type/signature/argument list,
then call GetProcAddress, then make all calls through that function
pointer.  There is a clever trick that the Cygwin DLL uses that reduces
this busywork -- look at for details.


Unsubscribe info:
Problem reports:

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