[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Having
GDB 7.0 is not a pre-requisite for DSF-GDB, DSF-GDB works with
GDB versions released back in 2006 i.e. GDB 6.6, even older ones can
work with minor issues, it's just that we don't do real testing on GDB's
released before 2006.
I
don't understand what you mean by pushing an agenda, Ericsson doesn't sell
CDT base products, we don't have any internal framework to push to the
CDT, we only want to have a thriving CDT community with a lot of
features, we don't care what is the name of the framework or where it
comes from.
Without a clear direction on the
default framework Mac people are fixing CDI because it's the default
launch and others are waiting to switch to DSF, ...
We
should stick we the plan, putting DSF-GDB as default will focus the community,
the sooner we do it for preliminary 7.0 the better.
On Thu, Feb 4, 2010 at 12:30 PM, Dominique Toupin
<dominique.toupin@xxxxxxxxxxxx>
wrote:
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.
Eclipse Lab doesn't exist yet. Wascana is up on SourceForge where
it's always been.
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.
But you only get those
features with GDB 7.0, no? Not everyone has access to it. As I mentioned in
other e-mails,
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?
The idea is not to have a debate at all, but to be all encompassing.
In fact, I don't think it's our place as an open community to push any one
agenda.
Doug.
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.
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
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev