Re: Change in core[master]: restore --enable-symbols option again -- was FYI: Cleanup of debug options

On 08/11/12 11:05, Norbert Thiebaud wrote:
> On Thu, Nov 8, 2012 at 2:01 AM, Stephan Bergmann <sbergman@redhat.com> wrote:
> > One problem with "S: symbols" is that "symbols" is a vague term here.
>
> http://www.network-theory.co.uk/docs/gccintro/gccintro_37.html
> "The debug compilation option works by storing the names and source
> code line-numbers of functions and variables in a 'symbol' table in
> the object file or executable. "
>
> My understanding of --enable-symbol is that it provide additional info
> so that a backtrace contain human-friendly info even for 'local
> function' (i.e the one that are resolved at compile time not at link
> time). How that is implemented is platform specific, and the fact that
> on some platform it is indistinguishable from --enable-debug-info is
> irrelevant.
> for me --enable-debug-info add enough to allow me to step through the
> code using a debugger, having all the variables name, line number etc,
> which is _not_ what --enable-symbol is aiming at.

yes, it is!

you need accurate per-line debuginfo both to get line numbers in crash
backtrace (which is really necessary in our codebase with functions that
may have 1000 lines) (also the extra stuff printed by our gdb python
helpers is quite useful to have in backtrace) and also for profiling,
because you want to know which of the 5 loops in some function eats all
the time.

that is why --enable-symbols adds "-g" to compiler commands.

> > It is not per-se about any kind of symbols (like not stripping internal symbols on ELF, etc.), 
> > but
>
> yes it is very much about symbols and not stripping them and making
> sure that there is enough of them (more than strictly necessary for
> the linker and kept in after link)

--enable-symbols also used to disable some stripping somewhere but that
is nowadays ~irrelevant because gbuild (AFAIK) doesn't strip anything
anyway.