Re: Failed breakpoint for C++ in gdb

Re: Failed breakpoint for C++ in gdb

[Alain Magloire]

From Daniel:
>On Tue, Jul 26, 2005 at 09:31:10AM -0400, Alain Magloire wrote:
>> Why is gdb so fussy about the argument order ?
>
> GDB generally matches the compiler-generated debug info.  There's a
> long-term plan to be more forgiving about this, but it's hard to
> implement that without slowing down symbol reading...
> 
> > (gdb) b foo(const char *)
> > Function "foo(const char *)" not defined
> > (gdb) b foo(char const *)
> > Breakpoint 1 at 0x....... file testing.cpp line 4.
> > 
> > So is there something I should do ? Do I have to reorder my arguments to
> put
> > the const last ?
> 
> Is this for command line use?  Try: b 'foo<TAB>

Niet, for front-end.

Is the "const char *" vs. "char const *" example consistent in GDB i.e. can
I assume this and do some mangling on my own to satisfy the pickiness of
GDB?

Re: Failed breakpoint for C++ in gdb

[Daniel Jacobowitz]

On Thu, Jul 28, 2005 at 05:12:56PM -0400, Alain Magloire wrote:
> From Daniel:
> >On Tue, Jul 26, 2005 at 09:31:10AM -0400, Alain Magloire wrote:
> >> Why is gdb so fussy about the argument order ?
> >
> > GDB generally matches the compiler-generated debug info.  There's a
> > long-term plan to be more forgiving about this, but it's hard to
> > implement that without slowing down symbol reading...
> > 
> > > (gdb) b foo(const char *)
> > > Function "foo(const char *)" not defined
> > > (gdb) b foo(char const *)
> > > Breakpoint 1 at 0x....... file testing.cpp line 4.
> > > 
> > > So is there something I should do ? Do I have to reorder my arguments to
> > put
> > > the const last ?
> > 
> > Is this for command line use?  Try: b 'foo<TAB>
> 
> Niet, for front-end.
> 
> Is the "const char *" vs. "char const *" example consistent in GDB i.e. can
> I assume this and do some mangling on my own to satisfy the pickiness of
> GDB?

This is not GDB's pickiness.  It is following whatever the compiler has
specified in debug information.  You could still query GDB for the
overloads in some fashion, I expect, but I don't know for sure.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: Failed breakpoint for C++ in gdb

[Alain Magloire]

> 
> It's completely at the whim of the compiler.  Whatever strings the
> compiler has put in the debug information, those are the ones GDB will
> use in symbol names.  It varies between GCC versions; I believe it also
> varies between formats.
> 

And the good news kept coming ;-(

On the same topic:

void String::check(int i) const
{
	if (i<0 || rep->sz<=i) throw Range();
}

int main() { ... }


(gdb) b String::check(int) const
Function "String::check(int)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) b "String::check(int) const"
Function "String::check(int)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) b 'String::check(int) const'
Breakpoint 1 at 0x4015bc: file 100992.cpp, line 150.

I'm curious to know why ("") double quotes are not working, but single quote
seems to do the job.  This is particular disturbing in the MI protocol where
it is clearly stated options/arguments containing spaces must be surrounded
with double quotes.

Anyway just curious, this was sent by the folks from MontaVista 8-). It is
too late for the front to deal with it, but for the next version, is this PR
(bugzilla/gnats) material?

Re: Failed breakpoint for C++ in gdb

[Daniel Jacobowitz]

On Fri, Jul 29, 2005 at 11:20:07AM -0400, Alain Magloire wrote:
> (gdb) b String::check(int) const
> Function "String::check(int)" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) n
> (gdb) b "String::check(int) const"
> Function "String::check(int)" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) n
> (gdb) b 'String::check(int) const'
> Breakpoint 1 at 0x4015bc: file 100992.cpp, line 150.
> 
> I'm curious to know why ("") double quotes are not working, but single quote
> seems to do the job.  This is particular disturbing in the MI protocol where
> it is clearly stated options/arguments containing spaces must be surrounded
> with double quotes.

Because the string is passed directly to the command line symbol name
parser, and it treats single quotes specially.  Really, you have to
read linespec.c to figure out what it's doing.

Basically, with the single quotes, you're getting a minimal symbol from
the ELF symbol table.  The others are trying for debug info lookups and
having some problem.

> Anyway just curious, this was sent by the folks from MontaVista 8-). It is
> too late for the front to deal with it, but for the next version, is this PR
> (bugzilla/gnats) material?

I suppose so; but no one's working in this area, so it's more likely
patch material :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: Failed breakpoint for C++ in gdb

[Alain Magloire]

> >
> > Is the "const char *" vs. "char const *" example consistent in GDB i.e.
> can
> > I assume this and do some mangling on my own to satisfy the pickiness of
> > GDB?
> 
> This is not GDB's pickiness.

Agreed, but for the user, with code source like this foobar(const char *p);
and then having the debugger insisting on only accepting foobar(char const
*p) for breakpoint is ... heu ... bizarre.

> It is following whatever the compiler has
> specified in debug information.  You could still query GDB for the
> overloads in some fashion, I expect, but I don't know for sure.
>

That may not be possible (the query) for the front-end.  Let me ask you
rephrase the question, is this behavior dependent of the type of debug info?
i.e. if I use dwarf-2 vs. stabs++, GDB will not refuse "char const *" I can
work around this if the behavior is consistent.

Anyway, thanks for the feedback.
 

Re: Failed breakpoint for C++ in gdb

[Daniel Jacobowitz]

On Thu, Jul 28, 2005 at 05:39:28PM -0400, Alain Magloire wrote:
> 
> 
> > >
> > > Is the "const char *" vs. "char const *" example consistent in GDB i.e.
> > can
> > > I assume this and do some mangling on my own to satisfy the pickiness of
> > > GDB?
> > 
> > This is not GDB's pickiness.
> 
> Agreed, but for the user, with code source like this foobar(const char *p);
> and then having the debugger insisting on only accepting foobar(char const
> *p) for breakpoint is ... heu ... bizarre.
> 
> > It is following whatever the compiler has
> > specified in debug information.  You could still query GDB for the
> > overloads in some fashion, I expect, but I don't know for sure.
> >
> 
> That may not be possible (the query) for the front-end.  Let me ask you
> rephrase the question, is this behavior dependent of the type of debug info?
> i.e. if I use dwarf-2 vs. stabs++, GDB will not refuse "char const *" I can
> work around this if the behavior is consistent.

It's completely at the whim of the compiler.  Whatever strings the
compiler has put in the debug information, those are the ones GDB will
use in symbol names.  It varies between GCC versions; I believe it also
varies between formats.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Failed breakpoint for C++ in gdb

[Alain Magloire]

Why is gdb so fussy about the argument order ?

For example:
int foo(const char *p) {
  int i = 0;
  i++;
  return i;
}

int foo() {
  int y = 0;
   y += 2;
  return y;
}

int main(int argc, char **argv) {
  Const char *p = "foobar";
  foo(p);
  foo();
  Return 0;
}

(gdb) b foo(const char *)
Function "foo(const char *)" not defined
(gdb) b foo(char const *)
Breakpoint 1 at 0x....... file testing.cpp line 4.

So is there something I should do ? Do I have to reorder my arguments to put
the const last ?
??

Re: Failed breakpoint for C++ in gdb

[Daniel Jacobowitz]

On Tue, Jul 26, 2005 at 09:31:10AM -0400, Alain Magloire wrote:
> Why is gdb so fussy about the argument order ?

GDB generally matches the compiler-generated debug info.  There's a
long-term plan to be more forgiving about this, but it's hard to
implement that without slowing down symbol reading...

> (gdb) b foo(const char *)
> Function "foo(const char *)" not defined
> (gdb) b foo(char const *)
> Breakpoint 1 at 0x....... file testing.cpp line 4.
> 
> So is there something I should do ? Do I have to reorder my arguments to put
> the const last ?

Is this for command line use?  Try: b 'foo<TAB>


-- 
Daniel Jacobowitz
CodeSourcery, LLC