Re: [cdt-dev] Parity features that don't work well (was: Signals view in CDT debugger)
I think it's simple, and don't imagine anyone would argue with what's
been said. If a feature doesn't work at all in CDI, or works very
poorly, or is poorly designed and non-critical, we absolutely should
not be working on it right now.
That said, I strongly believe 304096 is a critical issue. The fact
that you can NEVER suspend a Cygwin 6.8 gdb session with DSF-GDB
leaves it dead in the water, IMO. Sure, maybe it's a little flaky
with CDI, but it works most of the time. Cygwin only has 6.8, and
Cygwin is quite popular. We cannot with a serious face provide a
debugger that doesn't allow Cygwin users to suspend the target.
At 09:12 PM 4/13/2010, Marc Khouzam wrote:
I've only looked briefly at the signals feature so I'll let more
knowledgeable people answer your question.
I had to answer this email because you bring up a point that has
been bothering me (there's been a lot
of that on the list lately... I guess we are feeling the Helios pressure :-))
In more than one occasion, while investigating a CDI feature that we
labeled as a parity issue for DSF-GDB,
I have found that the feature had problems, even in CDI. I'm sure
it used to work well, but over the years,
things broke, and as you mention, maybe no one was using it, so no
one noticed it was broken.
For example (I won't give details in the email, but if someone is
interested, just ask):
- using full path names in debug view does not work well for CDI-
that is parity Bug 248627
- resume without signal did not work properly for CDI - that was
parity Bug 249223
- Run to Line did not work well across method calls for CDI - that
was parity Bug 233230
- interrupting a windows target windows target (at least for MinGw
6.8) does not work all the time with CDI - that is parity Bug 304096
But we are working hard to address those 'parity' bugs, when in
fact, they don't always work right in CDI.
So, when people look at the CDI vs DSF parity list, let's look at it
with a grain of salt, as some of those features may
not actually need to be on that list at all.
Re-reading myself, I realize I'm paraphrasing what Doug was saying
maybe we are too focused on 'parity' when we should simply work
towards improving the debugging
quality in the CDT. One example that comes to mind is the nice Pretty-printer
feature that Jens has written a difficult patch for. It is not a
parity issue, so we are not giving it as much attention;
but from a CDT user point-of-view, wouldn't that feature be better
than 'resume without signal' for example?
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of John Cortell [rat042@xxxxxxxxxxxxx]
Sent: April 13, 2010 7:20 PM
To: CDT General developers list.
Subject: [cdt-dev] Signals view in CDT debugger
I've started looking at the DSF parity task for the Signals view. I
figured the first thing I should do is see the feature in action with
a CDI session. Upon taking it for a spin, my first reaction was: are
people really using this feature? The reason I had that reaction is
that CDT makes no attempt to remember the settings from one debug
session to another. Finding the signal you want to disable in the sea
of available signals is cumbersome to begin with. Changing the values
for the signal is also nothing to sneeze at (requires too many clicks
for my tastes). But the kicker is that if after you've done all that,
prepare to do it again the next time you launch a debug session...for
the same program or any other one. I imagine cmdline gdb users would
employ a script that they could quickly and easily execute to tweak
the signal properties, so the gdb feature itself may be useful. I
just question whether the corresponding CDT view feature is, given
its current design.
If it isn't, we should put it in the low-priority parity bucket and
not consider it on the day we eventually decide whether or not to
keep DSF-GDB as the default for CDT 7.0.
cdt-dev mailing list
cdt-dev mailing list