[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
It
does give the impression you're selective
about which communities are worth encouraging (EDC) and which to do an end run
around (GDB).
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.
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.
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.
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.
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?
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
