(Not) debugging STL

(Not) debugging STL

[Alpár Jüttner]

Dear all,

I would greatly appreciate if anyone can help me with the following
issue.

Debugging C++ code using STL, I cannot figure out how to turn off
debugging the STL headers. Using the 'next' command is not a solution,
for example in case when I would like to step in the function 'f()' at a
line like the following.

f(v[i],v[w[i]+w[j]]);

In general, it would be often very useful for me to turn off debugging
of some source files I rely on. If it is a convertional .cc file, I can
do it by turning off putting the debug info into the related object
file. But what to do if I use templates/inline functions, thus the
implementations are in the header files?

Best regards,
Alpar Juttner

Re: (Not) debugging STL

[Daniel Jacobowitz]

On Thu, Mar 01, 2007 at 01:04:50PM +0100, Alpár Jüttner wrote:
> In general, it would be often very useful for me to turn off debugging
> of some source files I rely on. If it is a convertional .cc file, I can
> do it by turning off putting the debug info into the related object
> file. But what to do if I use templates/inline functions, thus the
> implementations are in the header files?

GDB does not have any way to do this - yet.  It's been proposed a few
times.

-- 
Daniel Jacobowitz
CodeSourcery

Re: (Not) debugging STL

[Alpár Jüttner]

> GDB does not have any way to do this - yet.  It's been proposed a few
> times.

It is quite a said news. Would it be hard to implement such a features?
Do gdb have some scripting language? If yes, would it be possible to
implement a macro that simply iterates 'step' while we are in a file
under /usr directory?

All the best,
Alpar

Re: (Not) debugging STL

[Daniel Jacobowitz]

On Thu, Mar 01, 2007 at 01:39:54PM +0100, Alpár Jüttner wrote:
> 
> > GDB does not have any way to do this - yet.  It's been proposed a few
> > times.
> 
> It is quite a said news. Would it be hard to implement such a features?

I don't know.  Maybe not, if someone came up with a good user
interface for it.  I recommend searching the list archives for more; I
think it was discussed within the past six months sometime.

> Do gdb have some scripting language? If yes, would it be possible to
> implement a macro that simply iterates 'step' while we are in a file
> under /usr directory?

GDB's current scripting language is not good enough for this.  I hope
to add a more powerful one this year.

-- 
Daniel Jacobowitz
CodeSourcery

Re: (Not) debugging STL

[Alpár Jüttner]

> I don't know.  Maybe not, if someone came up with a good user
> interface for it.  I recommend searching the list archives for more; I
> think it was discussed within the past six months sometime.

What I would suggest is a command say 'skip arg' or 'trust arg', where
arg is either a
      * file name (e.g. nobug.h)
      * a prefix (e.g. /usr/include or /usr/include/*)
Or even more:
      * a function
      * a class
      * a range of lines

> > Do gdb have some scripting language? If yes, would it be possible to
> > implement a macro that simply iterates 'step' while we are in a file
> > under /usr directory?
> 
> GDB's current scripting language is not good enough for this.  I hope
> to add a more powerful one this year.

Then, my next idea is to use the gdb interface of emacs. It should be
trivial to do a lisp function doing this, but I couldn't figure out how
to do that. For example how to obtain the file name of the currently
debugged line in emacs/gud/gdb?

Best regards,
Alpar

Re: (Not) debugging STL

[Nick Roberts]

 > > > Do gdb have some scripting language? If yes, would it be possible to
 > > > implement a macro that simply iterates 'step' while we are in a file
 > > > under /usr directory?
 > > 
 > > GDB's current scripting language is not good enough for this.  I hope
 > > to add a more powerful one this year.
 > 
 > Then, my next idea is to use the gdb interface of emacs. It should be
 > trivial to do a lisp function doing this, but I couldn't figure out how
 > to do that.

I'm not sure that I understand exactly what you're trying to do, but if
Daniel says it can't be done in GDB, then I dont think it can be done in
Emacs, as Emacs can only use the output that GDB gives it.

 >             For example how to obtain the file name of the currently
 > debugged line in emacs/gud/gdb?

This bit is straightforward: Emacs 21 uses --fullname option (although it is
hidden to the user).  For example, try:

gdb --fullname `prog'
(gdb) start

from the command line, then step a few times.  You'll see the current line,
that Emacs uses, get printed out.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: (Not) debugging STL

[Alpár Jüttner]

>  > Then, my next idea is to use the gdb interface of emacs. It should be
>  > trivial to do a lisp function doing this, but I couldn't figure out how
>  > to do that.
> 
> I'm not sure that I understand exactly what you're trying to do, but if
> Daniel says it can't be done in GDB, then I dont think it can be done in
> Emacs, as Emacs can only use the output that GDB gives it.

At first, I would simply write an emacs function that iterates the gdb
'step' command until we get out of any files whose full name starts
say /usr.
> 
>  >             For example how to obtain the file name of the currently
>  > debugged line in emacs/gud/gdb?
> ...
> from the command line, then step a few times.  You'll see the current line,
> that Emacs uses, get printed out.

I understand, that emacs parses this line, so I would like to know how
to have emacs to tell me the file name.

Regards,
Alpar

Re: (Not) debugging STL

[Alpár Jüttner]

Hi,

It seems to me that variable 'gud-last-last-frame' contains the name of
current source file. Thus I tried the following.

(defun my-step ()
  (interactive)
  (gud-step 1)
  (while (string-match "/usr/.*" (car gud-last-last-frame))
    (gud-step 1)))

However this did not work, I think because gud-step doesn't seem to
update the variable gud-last-last-frame. At least the following function
always prints the same string twice.

(defun m-step ()
 (interactive)
 (print (car gud-last-last-frame))
 (gud-step 1)
 (print (car gud-last-last-frame))
)

What to do then? Shall I use something else instead of gud-step?

Alpar


> On Sat, 2007-03-03 at 13:58 +0100, Alpár Jüttner wrote:
> >  > Then, my next idea is to use the gdb interface of emacs. It should be
> >  > trivial to do a lisp function doing this, but I couldn't figure out how
> >  > to do that.
> > 
> > I'm not sure that I understand exactly what you're trying to do, but if
> > Daniel says it can't be done in GDB, then I dont think it can be done in
> > Emacs, as Emacs can only use the output that GDB gives it.
> 
> At first, I would simply write an emacs function that iterates the gdb
> 'step' command until we get out of any files whose full name starts
> say /usr.
> > 
> >  >             For example how to obtain the file name of the currently
> >  > debugged line in emacs/gud/gdb?
> > ...
> > from the command line, then step a few times.  You'll see the current line,
> > that Emacs uses, get printed out.
> 
> I understand, that emacs parses this line, so I would like to know how
> to have emacs to tell me the file name.
> 
> Regards,
> Alpar
> 

Re: (Not) debugging STL

[Nick Roberts]

 > It seems to me that variable 'gud-last-last-frame' contains the name of
 > current source file. Thus I tried the following.
 > 
 > (defun my-step ()
 >   (interactive)
 >   (gud-step 1)
 >   (while (string-match "/usr/.*" (car gud-last-last-frame))
 >     (gud-step 1)))
 > 
 > However this did not work, I think because gud-step doesn't seem to
 > update the variable gud-last-last-frame. At least the following function
 > always prints the same string twice.
 > 
 > (defun m-step ()
 >  (interactive)
 >  (print (car gud-last-last-frame))
 >  (gud-step 1)
 >  (print (car gud-last-last-frame))
 > )

It probably doesn't print a different string because the interaction between
Emacs and GDB is asynchronous i.e. Emacs

Prints gud-last-last-frame
Sends "step" to GDB
Prints gud-last-last-frame
Receives GDB output
Updates gud-last-last-frame

so gud-last-last-frame is printed for the second time *before* it is
updated.

 > What to do then? Shall I use something else instead of gud-step?

If you look at the file that I have written, gdb-ui.el in Emacs 22, you'll
see it uses queues to solve this kind of problem i.e waits for the output of
one command before sending the next.

However I must point out it uses annotations which are an extension to the
fullname marker that I referred to earlier, and these are being deprecated
in favour of a new interface called GDB/MI.  All this is described in the
manual.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: (Not) debugging STL

[Daniel Jacobowitz]

On Sun, Mar 04, 2007 at 12:33:36AM +1300, Nick Roberts wrote:
> I'm not sure that I understand exactly what you're trying to do, but if
> Daniel says it can't be done in GDB, then I dont think it can be done in
> Emacs, as Emacs can only use the output that GDB gives it.

Oh, it probably could.  It could be done in GDB, just not yet - the
CLI scripting language is not adequate for this task.

-- 
Daniel Jacobowitz
CodeSourcery

Re: (Not) debugging STL

[Brian Dessent]

Alpár Jüttner wrote:

> It is quite a said news. Would it be hard to implement such a features?
> Do gdb have some scripting language? If yes, would it be possible to
> implement a macro that simply iterates 'step' while we are in a file
> under /usr directory?

At some point in the past someone posted some scripts to the mailing
list that created commands for easy display of the size/contents of
common STL container types (list, vector, tree, hash.)  I can't find the
post now, but I think it might be the same as this:
<http://www.stanford.edu/~afn/gdb_stl_utils/>.

Brian