Mail Archives: cygwin-developers/1998/06/10/11:40:00
> Gdb is currently lacking some very important features in cygwin. I
>was wondering what would be needed to get these features put in. The
>first is support for memory "core' dumps. It would seem that the exception
>routines would just have to dump out the various sections of memory
>in a format that let gdb read them back in. Of course this assumes that
>it can figure out where the sections of memory are (is there an easy
>way to do this?). Then gdb would just have to read them back in to
>a debugged process. This doesnt sound very hard, so I must be missing
>something :) What are the hard problems here?
It sounds pretty hard to me. You'll have to investigate what formats
gdb can understand, enhance them to deal with extra or missing Windows
details, and modify the .dll to produce a core file.
>The second feature is the ability to attach to running processes. Why
>is this harder than starting up a new debugged process. (Note: I'm not
>familiar with NT debugging facilities).
There is code in gdb already for debugging an active process. It uses
the DebugActiveProcess call but it doesn't work right, as someone on
the gnu-win32 mailing list has pointed out. It probably wouldn't be hard
to fix if you wanted to take a look at it.
>Finally, how much support is there for using windows debugging tools.
>Surely they must have been used to debug cygwin itself when it was first
>being brought up. Is it possible to emit symbol tables that windbg can
>grok? Does anyone have tips for using non-cygwin debuggers with cygwin?
There is no support for using native windows debugging tools. If I
remember correctly (and this is off the top of my head) native debug
format is Intel OMF with many extensions added by Microsoft. Possibly
there are now functions available for dealing with native formats.
Otherwise you'd have to "roll your own".
cgf
- Raw text -