Um, yeah, Wascana 1.0 keeps slipping. Work has been very busy leaving little time for me to work on it, but that should be clearing up in the next few weeks (I hope!). But as I did my testing for the release candidate of CDT 5.0.2, as I expected, I ran headlong into the gdb 6.8 issue that everyone seems to run into. I don't know how many people I see on my Feedjit log searching for: "gdb eclipse No source available for "ntdll!LdrAccessResource()". And I hope those people now find this blog entry instead.
The issue is that before gdb 6.8, there was no way to issue pending breakpoints using the MI protocol we use to talk to gdb. I think it was introduced in 6.7 from the CLI, but that doesn't help us. To support breakpoints in shared libraries, we need to keep retrying to set those breakpoints on every shared library load event. That worked for many years. But now, the break on shared library event in the MinGW gdb 6.8 really messes up the CDT. And it's mainly because it doesn't work in gdb any more.
So the solution is to add support for pending breakpoints, at least into the MinGW debugger target. But, alas, I think that's going to be a lot of work. And given I'm having trouble finding time to even get the p2 support for Wascana done, let alone dive into debug which I don't really have expertise on.
At any rate, the experience is so bad, I'm starting to think of holding off Wascana 1.0 until Galileo in June. I can make the p2 repo available so people can download the same thing I'm testing with. But until this debug issue is resolved, it's not an environment I'm happy to send out to the world.
That and there was an interesting conversation on the mingw users mailing list recently about the state of gcc 4.x for MinGW. I've lost faith that it's ready for prime time as well.
It's enough to make me wish we had a Windows debugger available and to complete our Visual C++ support (wink, wink, nudge, nudge to people who know who they are ;). For now, bear with me.
FYI I tried to install Wascana the other day on a work machine, but the only downloads that exist are self-installing exe files that require Administrator access to install. Given that I'm not an administrator on that machine, it was a complete non-starter.
ReplyDeleteWhy does installing it need Admin rights? Why can't I just unzip to install?
I assume you are using 0.9 Wascana. It uses a regular Windows installer and installs into Program Files like a normal Windows application. The idea is to make the install easy.
ReplyDeleteI'm not sure how that interacts with Admin rights. Being a software developer, I'd be crippled by a machine where I didn't have Admin rights.
Yeah, it was the 0.9 installer. Is there any reason why it must go into Program Files? After all, I can write to different areas (but PF only if I'm an Admin).
ReplyDeleteI didn't even get as far launching the application - that's more crippled than by not having Admin rights!
I appreciate that there's a wanting to make things easy approach, but why not build an installer that can be used by a user without Admin rights and make it even easier?
Anyway, it doesn't really matter, Wascana 1.0 is going to be a P2 repo anyway.
ReplyDeleteEven better :-)
ReplyDeleteI don't know if it makes you feel better. I've run into this bug many, many times, but I've learned to not let it bother me. In reality, I've gotten used to all kinds of issues with debuggers not being able to find source code in Java, and I just started to treat this bug in the same way. So what if it halts when my DLL loads? I'll just start it up again. But, I'm mostly doing JNI stuff, so I don't have to work with a lot of native code.
ReplyDeleteI've recently gave up using Eclipse GDB integration and switched to console-based GDB debugging. More typing, for sure, but for some reason I feel more, hm, natural this way and I seem to debug more efficiently.
ReplyDeleteThis is a bit off-topic but I have been unable to find an answer... I have been using CDT in linux for a long time with a portable (linux and windows) code base. Now I am also able to use CDT in windows to compile and (apparently) debug. I am using TDM's MinGW + MSYS for that. But the .project and .cproject files in linux have linux stuff and the ones in windows have windows stuff (binary parser, variables and so on). Until now I had the .project and .cproject files in the code repository but now things became problematic... Any suggestion in how to manage these files between windows and linux?
ReplyDeleteI run into that in my day job at Wind. I just have two configurations defined, one for Linux, one for MinGW. And I make sure the correct on is set as the active configuration.
ReplyDeleteIf you are talking about MinGW's GDB pending breakpoint support. Brandon Sneed had already solved the issue.
ReplyDeleteUse MinGW's GDB 6.8 Technology preview release in the following link:
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=20507&release_id=588606
Pardon me if I misunderstand your issue.
Hi Dough!
ReplyDeleteI just wanted to give you my congratulation for this project that helped me out to compile and run my "complex" program. It was created with MSVC 6.0 and I moved to Eclipse because of its functionalities (refactoring, word completion with template proposals, keyboard shorcuts, etc., etc,) Until now I was trying to compilate but I always got a lot o errors. After installing Wascana (and discovering that I had to add some system libraries WITHOUT EXTENSION in Tool Settings/Libraries ) I was able to compile it and build it successfully. I am very happy and would like to thank you for this. I had to search in several forums for a solution but they told it was impossible to use a MSCV toolchain in eclipse. Well thanks to you that is not true.
You're welcome :).
ReplyDeleteAnd don't call me Dough... ;)
OH I am really really sorry. I mistyped your name! Please excuse me Doug.
ReplyDelete