Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Parity features that don't work well (was: Signals view in CDT debugger)

Hi John,

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 earlier today:
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

Back to the top