Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: gdb@sourceware.org
Subject: Re: C++ Typedefs and symbol tables
Date: Mon, 20 Aug 2007 18:23:00 -0000	[thread overview]
Message-ID: <20070820182245.GA14063@caradoc.them.org> (raw)
In-Reply-To: <46C9D968.40809@st.com>

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


      reply	other threads:[~2007-08-20 18:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-20 17:11 Andrew STUBBS
2007-08-20 17:18 ` Daniel Jacobowitz
2007-08-20 17:35   ` Andrew STUBBS
2007-08-20 17:49     ` Daniel Jacobowitz
2007-08-20 18:12       ` Andrew STUBBS
2007-08-20 18:23         ` Daniel Jacobowitz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070820182245.GA14063@caradoc.them.org \
    --to=drow@false.org \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox