This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Backtrace_symbols and .symtab
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot comcom>
- To: Yury Gribov <y dot gribov at samsung dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>, Andreas Jaeger <aj at suse dot com>
- Date: Fri, 24 Oct 2014 08:29:57 -0500
- Subject: Re: Backtrace_symbols and .symtab
- Authentication-results: sourceware.org; auth=none
- References: <5447C4FF dot 7090507 at samsung dot com> <5447D7C0 dot 80705 at samsung dot com> <20141022164426 dot 4921E2C3ABB at topped-with-meat dot com> <5447E5EF dot 3080307 at samsung dot com>
- Reply-to: munroe at us dot ibm dot com
On Wed, 2014-10-22 at 21:14 +0400, Yury Gribov wrote:
> On 10/22/2014 08:44 PM, Roland McGrath wrote:
> > Please be specific about exactly what you propose. How would the program
> > find its own executable file from which to read .symtab?
>
> dladdr(3) already provides us with info about module which symbol
> belongs to so we can call this and use it's results to mmap .symtab (and
> .strtab) from the module and then use sections to map address to name.
> I'm indeed somewhat skimming over details because this email was
> intended as a general check whether this functionality would be
> liked/accepted by glibc folks.
>
> > The reason it
> > uses only .dynsym is that only .dynsym is part of the memory image in a
> > running program.
>
> Not only that but also search in .dynsym is much faster.
>
> > You mentioned sprof, but this is a completely different case. That's a
> > program that reads an ELF file off disk.
>
> Sure, .symtab would need to be read from disk on demand (and probably
> cached) somewhere inside backtrace_symbols.
>
Some tools that use backtrace need fast/simple function and this
proposal would slow it down significantly.
This is a bad idea.