gdb needs full C++ function signature to set a breakpoint

gdb needs full C++ function signature to set a breakpoint

[Klaus Zeitler]

Hello,
I'm debugging a program with automatically generated C++ code (hundreds of
classes with lots of ugly looking, but unique, i.e. not overloaded member
functions). When I try to set a breakpoint on such a C++ member function name
gdb always says: "The class ... does not have any method named ...".

For example using the following function:
aMOTxAmp_Actor::choicePoint28_checkAST(SPD<MODCInvokeActionReq, SP<MODCBase> > const*, prMOAccess::Conjugate*)
(that gets mangled to
_ZN14aMOTxAmp_Actor22choicePoint28_checkASTEPK3SPDI19MODCInvokeActionReq2SPI8MODCBaseEEPN10prMOAccess9ConjugateE)
gdb says:
(gdb) b aMOTxAmp_Actor::choicePoint28_checkAST
the class aMOTxAmp_Actor does not have any method named choicePoint28_checkAST
Hint: try 'aMOTxAmp_Actor::choicePoint28_checkAST<TAB> or 'aMOTxAmp_Actor::choicePoint28_checkAST<ESC-?>

Thus I always need to have these function names expanded with '...<tab>'.
That's not very convenient but ok as long as I don't want to set breakpoints
via .gdbinit (in the latter case I use the mangled names).

Now what puzzles me is, that when I reduce my 100MB image to a small example
with only one or two of these weird functions, gdb is able to set the
breakpoint in the example above.
BTW I've checked that in both cases 'nm <image> | grep choicePoint28_checkAST'
returns exactly one (and the same) match.

Thanks

Klaus

-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
|  Email:             kzeitler@lucent.com  |
 ------------------------------------------
---
The only problem with being a man of leisure
is that you can never stop and take a rest.

Re: gdb needs full C++ function signature to set a breakpoint

[Daniel Jacobowitz]

On Thu, Jul 07, 2005 at 10:16:05AM +0200, Klaus Zeitler wrote:
> Hello,
> I'm debugging a program with automatically generated C++ code (hundreds of
> classes with lots of ugly looking, but unique, i.e. not overloaded member
> functions). When I try to set a breakpoint on such a C++ member function name
> gdb always says: "The class ... does not have any method named ...".

This usually means that debugging information for the class was
incorrect, was incorrectly interpreted, or has not been loaded for some
reason.  I'm afraid that's as helpful as I can be without a testcase...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdb needs full C++ function signature to set a breakpoint

[Klaus Zeitler]

I figured out the difference between my small example and the big image.
For the example image gdb correctly recognizes the program as C++, i.e. says:
"The current source language is "auto; currently c++"."
whereas for the real image gdb claims, that it's c.
So a simple "set lang c++" is all that was needed.

Now I would like to know why gdb thinks that this is a c image.
Could it be that gdb decides that by searching main()?

Some time ago somebody had the clever idea to link our image with a
library for testing that contained a 2nd main() in a c file. To avoid linker
errors he made main() a weak symbol.
When I remove this 2nd main() function, the linker now finds the original
main() function in a c++ file and now gdb identifies the image as C++.

Klaus

-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
|  Email:             kzeitler@lucent.com  |
 ------------------------------------------
---
I have made this letter longer than usual because I lack
the time to make it shorter.             -- Blaise Pascal

Re: gdb needs full C++ function signature to set a breakpoint

[Daniel Jacobowitz]

On Fri, Jul 08, 2005 at 04:09:44PM +0200, Klaus Zeitler wrote:
> I figured out the difference between my small example and the big image.
> For the example image gdb correctly recognizes the program as C++, i.e. says:
> "The current source language is "auto; currently c++"."
> whereas for the real image gdb claims, that it's c.
> So a simple "set lang c++" is all that was needed.
> 
> Now I would like to know why gdb thinks that this is a c image.
> Could it be that gdb decides that by searching main()?

GDB does not have a single impression of the language - it depends on
the current location in the code.  But yes, before the program is
started, the current "location" used is main().

This is a wart; it'd be nice if the CLI did not depend on this for some
things that it does presently, but it isn't clear how to fix it.

-- 
Daniel Jacobowitz
CodeSourcery, LLC