I've been working over the past week trying to get process interrupts working on Windows so that we can get suspend working again with gdb. The suspend call gets translated to a SIGINT signal raised on the process, which on Windows gets converted into a Control C event. For some reason it stopped working lately, mind you I don't remember ever actually trying it. It was fun, though. It got me back to my roots as a Windows developer and renewed my dislike for Hungarian notation.
Now that I got it working, though. I am finding that when you suspend gdb, both the cygwin version and the mingw version, that you end up in a pretty useless state. The stack trace has gdb totally confused. The addresses don't even look like real addresses. I thought for a moment that it was because of something I did in the CDT. But when I tried it from the command-line I got the same result. I did a Google search and looked at the cygwin and mingw forums and couldn't find anything useful. Maybe no one cares. Maybe it's my machine. Who knows (do you?).
At any rate, it has led me down a path to take a deeper look at how gdb is implemented and try and debug it myself. This is something that I've wanted to do for a while. We use gdb as our debugger in QNX Momentics so I may be able to help out our gdb guys too. It'll also give me something else to test the CDT with. I'm not sure we've tested Makefile projects enough in CDT 4 so this will give me a chance to do that. My focus will be on MinGW gdb and it would be cool to be able to contribute any fixes I come up with, or even a port to the latest gdb back to these guys.
Please, please please please, if you have trouble with GDB... try the GDB mailing list. The MinGW project has been, unfortunately, uninterested )so far as we can tell) in contributing their changes - that's why they're on such an old version. But there's lots of other people who use GDB on Windows and know about it and would benefit from improving it.
ReplyDeleteThe reason GDB can't backtrace out of a suspended Windows process is because the Windows system DLLs are very tricky to unwind from, and you can't readily get enough symbol information to do it. You can if you use one of Microsoft's APIs (I don't remember what it's called) that lets you retrieve stuff from the symbol server and query it, but you can't build that with the headers in mingw32, and it doesn't work the same way GDB does anyway.
I've thought about this before and it makes me think that we need a conversion program - query the symbol file from a separate non-GDB program and record something like a mocked-up ELF file that explains where the symbols are and how to unwind from them.
The truth is it has been some time now since I haven't seen Eclipse CDT interrupt a gdb debugged process successfully.
ReplyDeleteAlso, plain old Cygwin DDD does seem to be able to interrupt a debugged process using a running 6.7 gdb/gdbserver configuration both running on Cygwin too.
Maybe if CDT could implement this functionality like DDD does this could make it work again?
I spend also a whole day to analyze why I was not able to supsend my gdb from eclipse. Finally I found, that there was no kill.exe found within the path, which is used by eclipse to send a SIGINT to the cygwin gdb. So, if anybody is able to debug with eclipse and gdb, and is NOT able to suspend a running debug target, check if there is a cygwin kill.exe.
ReplyDelete