C++ Typedefs and symbol tables

C++ Typedefs and symbol tables

[Andrew STUBBS]

Hi,

I have encountered a problem setting breakpoints on overloaded C++ 
functions: when I specify the function signature, I have to use the 
canonical type name, not the typedef name used in the source I am 
looking at. (I am aware it prompts where no signature is given, but that 
possibility is not available to scripts, for example).

I'm using GDB 6.5 here. Apologies if this is a well known problem I've 
somehow failed to find on Google, or has been fixed since then.

E.g.

class C;
typedef C t;
void f (t);

(gdb) break f(C)    -> OK
(gdb) break f(t)    -> bad

"info functions" lists the function using the name "C". This is 
consistent with nm, so I assume it is getting this from the symbol 
table. I suppose it makes sense that the signature in the symbol table 
uses the canonical name.

The dwarf debug information, on the other hand, shows the function with 
the typedef name used in the source code. It also contains the proper 
mapping from typedef name to actual class name.

Would it not be possible to use the debug information, where available, 
to canonicalize the type names before attempting to match the function 
signatures, at least for the purposes of setting breakpoints?

Thanks

Andrew

Re: C++ Typedefs and symbol tables

[Daniel Jacobowitz]

On Mon, Aug 20, 2007 at 06:10:42PM +0100, Andrew STUBBS wrote:
> Hi,
> 
> I have encountered a problem setting breakpoints on overloaded C++ functions: 
> when I specify the function signature, I have to use the canonical type name, 
> not the typedef name used in the source I am looking at. (I am aware it prompts 
> where no signature is given, but that possibility is not available to scripts, 
> for example).

Check whether you are ending up with a search based on the function's
symbol or minsym.  The mangled name always uses the canonical type
name (for obvious ABI reasons).

> The dwarf debug information, on the other hand, shows the function with the 
> typedef name used in the source code. It also contains the proper mapping from 
> typedef name to actual class name.
> 
> Would it not be possible to use the debug information, where available, to 
> canonicalize the type names before attempting to match the function signatures, 
> at least for the purposes of setting breakpoints?

Yes, but it's a lot of work.  We can not currently canonicalize
anything during lookup because we do not canonicalize during symbol
reading; and just turning that on slows things down considerably.  The
cp-names.y parser was intended for exactly this.

-- 
Daniel Jacobowitz
CodeSourcery

Re: C++ Typedefs and symbol tables

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> Check whether you are ending up with a search based on the function's
> symbol or minsym.  The mangled name always uses the canonical type
> name (for obvious ABI reasons).

Symbol or minsym? Sorry, I'm not at all familiar with this area of the 
debugger.

> Yes, but it's a lot of work.  We can not currently canonicalize
> anything during lookup because we do not canonicalize during symbol
> reading; and just turning that on slows things down considerably.  The
> cp-names.y parser was intended for exactly this.

Surely converting the (typically) 2-3 typenames in a signature, such 
that they match the canonical form used by the ABI, would not take much 
time, would it?

I can believe that any task in this area would require depressing 
amounts of infrastructure work, though. :(

Oh well, just an idea.

Andrew

Re: C++ Typedefs and symbol tables

[Daniel Jacobowitz]

On Mon, Aug 20, 2007 at 06:35:29PM +0100, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> > Check whether you are ending up with a search based on the function's
> > symbol or minsym.  The mangled name always uses the canonical type
> > name (for obvious ABI reasons).
> 
> Symbol or minsym? Sorry, I'm not at all familiar with this area of the 
> debugger.

Symbols come from .debug_info and have type information.  minsyms come
from the ELF .symtab section, and do not.

> > Yes, but it's a lot of work.  We can not currently canonicalize
> > anything during lookup because we do not canonicalize during symbol
> > reading; and just turning that on slows things down considerably.  The
> > cp-names.y parser was intended for exactly this.
> 
> Surely converting the (typically) 2-3 typenames in a signature, such that they 
> match the canonical form used by the ABI, would not take much time, would it?

2-3 typenames is not typical, in C++ programs.  It added around 30%
time in my testing.

-- 
Daniel Jacobowitz
CodeSourcery

Re: C++ Typedefs and symbol tables

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> Symbols come from .debug_info and have type information.  minsyms come
> from the ELF .symtab section, and do not.

Ah, OK. How do I determine this, and how do I get it to use the proper 
symbols if it has chosen the wrong ones?

I know that the debug info contains the definition given in the source - 
at least for one example I looked at, anyway. It couldn't have arrived 
at the version given by 'info functions' without canonicalizing the 
debug info, so I assume it must be using the (already canonical) minsyms 
only.

> 2-3 typenames is not typical, in C++ programs.  It added around 30%
> time in my testing.

Oh? I'm talking about converting something like

	Int32 f(Bp,Int16)
  to
	int f(B*,short)

(where Bp is an example of a typedef), and only for parameters given to 
breakpoint commands and the like.

There's only 3 types in that (four if you count the function type), and 
breakpoint commands wouldn't come up _too_ often, so surely it couldn't 
take that much time?

Surely we are talking at cross-purposes?

Andrew

Re: C++ Typedefs and symbol tables

[Daniel Jacobowitz]

On Mon, Aug 20, 2007 at 07:11:52PM +0100, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> > Symbols come from .debug_info and have type information.  minsyms come
> > from the ELF .symtab section, and do not.
> 
> Ah, OK. How do I determine this, and how do I get it to use the proper symbols 
> if it has chosen the wrong ones?

Sorry, there's no easy answer to either of these questions.

> I know that the debug info contains the definition given in the source - at 
> least for one example I looked at, anyway. It couldn't have arrived at the 
> version given by 'info functions' without canonicalizing the debug info, so I 
> assume it must be using the (already canonical) minsyms only.

Often the minsym's name is used even when dealing with the full
symbol.  I worked on stopping this, and I hope I will have a chance to
try again soon.  You can find more information by searching for
DW_AT_MIPS_linkage_name.

> > 2-3 typenames is not typical, in C++ programs.  It added around 30%
> > time in my testing.
> 
> Oh? I'm talking about converting something like
> 
> 	Int32 f(Bp,Int16)
>  to
> 	int f(B*,short)
> 
> (where Bp is an example of a typedef), and only for parameters given to 
> breakpoint commands and the like.
> 
> There's only 3 types in that (four if you count the function type), and 
> breakpoint commands wouldn't come up _too_ often, so surely it couldn't take 
> that much time?
> 
> Surely we are talking at cross-purposes?

That is not at all a typical function name for a typical C++ program
:-)  In my experience most programs that bother to write in C++ do it
with intention of taking advantage of templates, and this blows up the
number of type signatures in function names dramatically.  Even
namespaces and classes do so.

-- 
Daniel Jacobowitz
CodeSourcery