Well, I certainly wasn't making a personal attack on the people working on gdb for mingw, nor was I challenging their character. The issues I was running into was much more technical than that and involved stack unwinding when mixing msvc and gcc built DLLs. Or maybe it was stopping on shared library events giving me garbage stacks or stopping at the wrong time. I'm not a debugger expert, but It was more complicated than tty's at any rate.
I'm just not confident that the Windows platform is getting a lot of love from the gcc and gdb communities, and if that's the case, I'm OK with that.. It is a bit of a niche market. Or maybe that's changing lately and I'll certainly take a look at the 7.0.1 gdb that's now up on the mingw site. If it works with GDB/DSF, then I'll be happy. If not, I do know that EDC seems to work there and there is effort going into making it work well there.
On Wed, Feb 3, 2010 at 9:18 AM, Daniel Jacobowitz <dan@xxxxxxxxxxxxxxxx>
This really pushes my buttons.
Instead of constantly complaining about MinGW GDB, you could submit
bug reports or try to understand the actual problem. For someone
who's so gung-ho about community involvement, you're selective about
which communities are worth being involved in (or even worth
encouraging) and which to do an end run around.
For instance, this might be the mostly intractable problem of
_isatty(). There's no API equivalent to pseudo-TTY's on Windows;
if you run a console program from GDB, it has to either pop up a new
console or else run the program with its standard handles connected
to a pipe. This results in buffered output and people complain about
missing printfs. I think current GDB does a little better.
An experienced Windows developer might be able to make it do
It could be any number of other problems. This random poster is
complaining about GDB 5.3. That is a seven year old release. For
some perspective on how long ago that is: this is like walking up to
you and complaining about a bug in CDT 1.0.
cdt-dev mailing list