Debugging with KDevelop

[Vladimir Prus]

On Monday 24 October 2005 00:33, Sascha Cunz wrote:

> > 1) You cannot define any "expansion rule": I use everywhere wxString
> > object types which are the wxWidgets' strings. I just cannot see their
> > contents unless I add as watch expression: (char*)str.m_pchData, or
> > unless I expand all the times the variable tree clicking on the variable
> > until I reach the parent class and I can finally expand its m_pchData
> > variable manually. (also, when using Unicode, I cannot see string
> > contents expanding the variables in the tree; probably because "wxChar"
> > is mapped to "wchar_t" instead of "char"...).
> >
> > This is a big loss of time when you have to inspect many variables. In
> > MSVC6 there is the AUTOEXP.DAT file where you can define simple expansion
> > rules. IMHO this feature would make the use of debugger 10/20 times
> > faster.
>
> Here you really have a point! Just for the records: They dropped it (or i
> didn't find it yet) in the .NET version of MSVC - which i personally feel
> is a pitty, because this is really a rocking feature.
>
> Maybe Vladimir can have a look, if it's posible to solve this. However,
> autoexp.dat always seemed a little mystic to me, if we can implement the
> backend, we should also implement a nice frontend to it.

My thoughts are in http://bugs.kde.org/show_bug.cgi?id=94313
Essentially, it's not possible to reliable implement automatic pretty-printing 
of anything, because gdb helpfully includes variables that were not 
initialized in "info locals" output. Example:

     string s = "fooo";
     // lots of code
     QUrl url = ....;

when inside <lots of code>, gdb will still report 'url' as live, and trying to
call QUrl::prettyURL on an uninitialized object will lead to segfault. It's 
possible to ignore that, but then the program might randomly crash.

It might be possible to implement on-demand pretty printing, but it's not 
clear whether it's better to use gdb macro mechanism, or something new. I'd 
clearly prefer to describe pretty-printing rules in Python, but that would be 
extra work.

> > 2) You cannot see the return values of the functions. This is a bit
> > problematic specially when the returned value is used directly in other
> > expressions, without storing it in a variable...
>
> I've no clue if that is posible with GDB at all, but maybe Vladimir can
> enlighten us here.

Yes, it's possible. As I say in another email, user interface is the only 
question.

>
> > 3) To make stepping a little easier, it would be nice (but this has low
> > priority, IMHO) to give to the user a way to select (maybe using regexp)
> > the functions where he *never* wants to step into so that if he uses
> > Step-into over one of those functions (maybe just because there are a lot
> > of them and he pressed the wrong key :-)) the debugger instead just does
> > a Step-Over.
>
> This one would really be a good feature. No IDE i've seen up to now
> supports this. Though it could reduce debugging time a lot.

Seconded. It might be possible to implement using the recent "tracepoints" as 
a basis.

  - Set a breakpoint on a function in question
  - As a tracepoint action set "finish"

Except this won't work yet, because "tracepoints" don't allow to specify 
arbitrary commands.

- Volodya