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.
Doug.
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.
Cheers,
Doug.
On Wed, Feb 3, 2010 at 9:18 AM, Daniel Jacobowitz
<dan@xxxxxxxxxxxxxxxx> wrote:
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
CodeSourcery
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev