Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] MinGW gdb

Hi Mikhail,
I also don't believe in one universal lunch config, we will always need to provide a way to add/hide features.
The only thing I am saying is with all the new features in DSF-GDB it's good enough for many people/companies.

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
Sent: 4-Feb-10 13:28
To: CDT General developers list.
Subject: RE: [cdt-dev] MinGW gdb

It's too optimistic to believe in the bright future when we will have one universal launch configuration for GDB. Many clients not only add new features but also hide the features they don't support.
Pawel will correct me if I am wrong, but one of the main advantages of DSF is its service-oriented architecture. You can build your debugger by combining DSF services, but to launch it you need to write a special launch configuration. Same is with DSF/GDB.
Sorry, I have been trying not to interfere in this discussion :)

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Dominique Toupin
Sent: Thursday, February 04, 2010 5:30 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] MinGW gdb

I am taking your offer for the cdt.p2 installer, do you when when we can start doing it on Eclipse Lab? If you need help for Android/Moblin/ or other Linux let me know we can do something, I am actually doing talks on debug at multi-core, embedded system and possibly at embedded Linux, hopefully it will help the CDT community.
You are saying below the CDT community is doing +400,000 download and that today they are using GDB, the best way to not mess up the community is to provide GDB as default launch.
With all the new features in DSF-GDB (e.g. multi-process, non-stop, tracepoint, etc.) less and less companies have to re-create their own launches or do addition to CDT-DSF-GDB, having a stable/rich-features/ubiquitous solution for CDT debug can only help the CDT community and should help to attract more people.
The plan was to go for DSF-GDB in Helios, creating a debate over GDB vs EDC can give the impression of being partisan.
I can understand you had bad experience with MinGW GDB in the past, especially with old version, today we have a nice collaboration with the GDB community, people from both CDT and GDB community are following both mailing list, doing patches, etc.
I know from Marc K. that the GDB community has been very cooperative in order to get a nice GDB integration in CDT, they even did patches only for us (Marc please provide example). If you have a need about JNI debug, write something on the GDB mailing list we might make progress.
If you really want to have a debate of GDB vs EDC, we can continue to give arguments and document them on the CDT wiki, is the debate really needed?

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: 3-Feb-10 17:53
To: CDT General developers list.
Subject: Re: [cdt-dev] MinGW gdb

On Wed, Feb 3, 2010 at 4:08 PM, Dominique Toupin <dominique.toupin@xxxxxxxxxxxx> wrote:
It does give the impression you're selective about which communities are worth encouraging (EDC) and which to do an end run around (GDB). 

Given that I have no vested interest in GDB, I'm not sure why I personally need to promote it. EDC is an interesting addition to our ecosystem and I'm curious to see where it fits in. And I'm especially curious if it helps solve my JNI debugging problem.
My understanding from CDT meeting discussions (which don't have minutes most of the time) was that we would leave CDI for Galileo and put DSF-GDB for Helios, in the last meeting (which has documented minutes), the plan for CDT is not clear anymore ("Which one should be the default? EDC is good for Windows"). Not having a clear direction doesn't help companies to contribute to open source projects and doesn't help to focus the existing community, it takes time to be up to speed with a new framework, people are hesitant to do it unless they know the knowledge will help them in the future and that a stable/rich set of features is available. 

The direction is decided by the community and what people contribute to. Pretty much all current contributions are based on DSF. So if there is confusion over whether to pick DSF or CDI, then it should be clear. CDI is a deprecated framework.

Now, whether people pick EDC over GDB, is a matter for the community and we are giving them the choice. I have no idea what the people doing the 400,000+ downloads of CDT prefer. Today they are using CDI with GDB. So if we're going to switch to whichever, we need to make sure we don't mess them up too badly. Other than that, the adopting vendors and distribution makers can pick whatever debugger and framework they like.
In the debug area, many companies are making big contributions to GDB, e.g. multi-architecture, multi-OS support  (IBM, Ericsson), Python scripting (RedHat, etc), dynamic and static Tracepoint (CodeSourcery, Ericsson, Polytechnique), improved C/C++ debug (RedHat/Archer), Multi-Process/exec (CodeSourcery, Freescale, etc.), non-stop (CodeSourcery, Ericsson) reversible debug (VMware, Virtutech, etc.), I could go on, especially for upcoming features like core awareness. A lot more companies are making smaller contribution and using GDB extensively, DSF/GDB has a lot of features, it's been around for many years, GDB stubs works on all targets that I know of, from RTOS, to native Linux, to windows, to emulator/simulators (e.g simics), to JTAG, we can even use the same DSF/GDB binary on host to debug different targets. GDB is the most ubiquitous debugger I know. For the DSF-GDB, I think WindRiver  (e.g. Pawel, Randy, etc.) did a great job with the initial DSF-GDB implementation and we were happy to contribute to it in order to help build the future debug solution for CDT.

Again, GDB is just one of the external debuggers that we integrate with. It's the most popular, but it's not up to the CDT to pick what debugger people use. CDT is a platform. Don't confuse the exemplary integration we have with the gnu tools as an endorsement of them, only an acknowledgement of their proliferation. The fact that we have integrations with the gnu tools actually enters a grey zone with the IP rules at Eclipse, so we do need to tread carefully.
I am afraid that if CDT changes direction again, companies who are using GDB and Eclipse will continue to wait for contributions until CDT makes up it's mind and has a stable/rich set of features for debug, going EDC as default is narrowing and doesn't help collaboration with Linux Foundation on tools (something equivalent to LSB but for tools). As you know we are planning a packaging of CDT + Linux Tools + GNU Tools for Linux targets, hopefully it will give more visibility to the CDT in the Linux community and attract more people (Linux is a fast growing community). We can do it on Eclipse Lab under some form of CDT distribution including GNU binaries.

That's fine. As you do your own distribution, you are free to pick the debugger and integration you'd like. The CDT is a platform that supports many debugger integrations. You aren't forced into any particular one.
To answer your question below yes DSF/GDB is working with MinGW gdb 7.0.1 on windows and you can use it in Wascana, hopefully we can work together on the CDT distribution.

Wascana is a pet project of mine, for legal reasons not a part of the CDT project, but intended to help promote CDT in the Windows development community. And, as it is turning out, it's an exemplary implementation of an p2 installer that gives you a complete IDE including tools and libraries. Feel free to reuse some of the concepts from it and the cdt.p2 plug-in and I can help you get started with that.

For Linux, I'd prefer to spend time helping the Linux distro guys who all have their own external tools and install strategy. Fedora is doing a great job at integrating the CDT. Ubuntu and Debian need help. I might do something with Moblin, but I'd prefer they release an SDK with CDT in it. And Android is something different all together. That's enough to fill my days.

I guess putting something together in order to make the DSF-GDB default choice more obvious would be good, the above + list of features could be a start?

Sure. However, my plan for the next couple of weeks is to take another look at our launch story. I hate the fact we have a default. It should be related to the toolchain that the user is using for their project. Then when you define your toolchain, you can say what debugger and integration framework to use. For our exemplary toolchain support, where DSF/GDB works well, we can hook it up. Where it doesn't we can use alternatives.

I need to and plan on being non-partisan in this debate of GDB versus EDC. I hope you aren't looking to me for guidance on what to choose. That's for you the community to decide, if you feel you have to at all.


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: 3-Feb-10 10:42
To: CDT General developers list.
Subject: Re: [cdt-dev] MinGW gdb

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> wrote:
On Wed, Feb 03, 2010 at 01:22:07AM -0500, Doug Schaefer wrote:
> Here's an example of why I'd like to go EDC for Wascana. MinGW gdb is a bit
> of a mess.

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
better still.

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.

Daniel Jacobowitz
cdt-dev mailing list

cdt-dev mailing list

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Back to the top