setting breakpoints with C++ typedef names [was: Re: debug information]

setting breakpoints with C++ typedef names [was: Re: debug information]

[Benjamin Kosnik]

> 
> But still function names include full type name: `b 'bar(basic_pod<int>)''.
> Not much of a problem in this case, but sometimes the full name is very
> long...

Oh. I finally understand you. Yes, this is a drag.

You want to be able to do:

(gdb) b bar(ipod)

instead of

(gdb) b bar(basic_pod<int>)

As you've noticed, this doesn't currently work. (x86-linux, mainline
gcc, gdb (6.5-13.fc6rh))

(gdb) b bar(ipod)
Function "bar(ipod)" not defined.

As you stated, you have to:

(gdb) b bar(basic_pod<int>)
Breakpoint 4 at 0x80489d7: file debug.cc, line 24.

I suggest reporting this to the gdb list (gdb@sourceware.org). You
might want to title that email something like "setting breakpoints with
C++ typedef names" or something more descriptive. Here, I've done that
for you.

To me, it looks like enough information is present in the debuginfo to
support this kind of usage. However, I am no expert in this area.

-benjamin

ps. Here's the test case

 
template<typename T>
struct basic_pod
{
  typedef T value_type;
  value_type _M_data;
};

typedef basic_pod<int> ipod;

void
bar(ipod p)
{
  p._M_data = 0;
}

void
bar(int i)
{
  ++i;
}

int main()
{
  ipod p;
  bar(p); // b bar(ipod)
  bar(5); // b bar(int)
  return 0;
}

Re: setting breakpoints with C++ typedef names [was: Re: debug information]

[Daniel Jacobowitz]

On Wed, Nov 22, 2006 at 01:03:41PM +0100, Benjamin Kosnik wrote:
> I suggest reporting this to the gdb list (gdb@sourceware.org). You
> might want to title that email something like "setting breakpoints with
> C++ typedef names" or something more descriptive. Here, I've done that
> for you.
> 
> To me, it looks like enough information is present in the debuginfo to
> support this kind of usage. However, I am no expert in this area.

I don't think that GDB will ever support this.  It's one of a batch
of C++ improvements that would be nice to have, but getting it right
would require most of a C++ front end.  And for various reasons,
I don't think that reusing the g++ front end would be practical.

We could probably get it to work in strictly limited cases, though.

-- 
Daniel Jacobowitz
CodeSourcery

Re: setting breakpoints with C++ typedef names [was: Re: debug information]

[Martin Sebor]

Benjamin Kosnik wrote:
>>But still function names include full type name: `b 'bar(basic_pod<int>)''.
>>Not much of a problem in this case, but sometimes the full name is very
>>long...
> 
> 
> Oh. I finally understand you. Yes, this is a drag.
> 
> You want to be able to do:
> 
> (gdb) b bar(ipod)
> 
> instead of
> 
> (gdb) b bar(basic_pod<int>)

This is especially troublesome when the real type is private to
the implementation, as in, for example,

     void foo (std::map<T, U>::iterator);

In order for a user to set a breakpoint on foo they need to know
that the type of libstdc++'s map<T, U>::iterator is really called
     std::_Rb_tree_iterator<std::pair<const T, U> >
(and something completely different when using a different
implementation of the library).

I expect this use of private names to become even more pervasive
when (and if) typedef templates are implemented.

Martin

Re: setting breakpoints with C++ typedef names [was: Re: debug information]

[Paul Pogonyshev]

Martin Sebor wrote:
> Benjamin Kosnik wrote:
> >>But still function names include full type name: `b 'bar(basic_pod<int>)''.
> >>Not much of a problem in this case, but sometimes the full name is very
> >>long...
> > 
> > 
> > Oh. I finally understand you. Yes, this is a drag.
> > 
> > You want to be able to do:
> > 
> > (gdb) b bar(ipod)
> > 
> > instead of
> > 
> > (gdb) b bar(basic_pod<int>)
> 
> This is especially troublesome when the real type is private to
> the implementation, as in, for example,
> 
>      void foo (std::map<T, U>::iterator);
> 
> In order for a user to set a breakpoint on foo they need to know
> that the type of libstdc++'s map<T, U>::iterator is really called
>      std::_Rb_tree_iterator<std::pair<const T, U> >
> (and something completely different when using a different
> implementation of the library).

Another important problem (and most important to me, since I set up
breakpoints using Tab-completion anyway) is that it makes backtraces
and similar stuff virtually unreadable.

Paul