This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strip, Linux's backtrace_symbols API, and GCC optimizations levels


Thanks for your reply, Ian.

Brent> Also, is there a way to have my cake and eat it too, which is to be
able to
Brent> use -O2, but still have backtrace_symbols work like it would at lower
Brent> optimization levels?

Ian> It depends on what is missing.  backtrace_symbols will never show calls
Ian> for which the callee has been inlined.  

Inlining is what is happening I think, as my tinker-toy app has a
chain of very simple functions that are undoubtedly getting inlined at
-O2 level.  I believe I can live without seeing the inlined functions
(if I want more, then I'll be using a debug build with GDB).

Ian> However, it should normally be
Ian> able to show non-inlined calls regardless of the optimization level, as
Ian> long as you compile C++ or compile with the -fexceptions or
Ian> -funwind-tables option.

I can arrange that, as ultimately my use of backtrace_symbols will be
needed in a C++-based app.

Ian> That said, backtrace_symbols will not work
Ian> reliably if called from a signal handler.

Uh oh, ok, the backtrace_symbols man page says nothing of this
limitation.  Can you provide more info as to why it is not reliable
from a signal handler?

Thanks for your help,
Brent

-- 
View this message in context: http://www.nabble.com/strip%2C-Linux%27s-backtrace_symbols-API%2C-and-GCC-optimizations-levels-tp23348886p23362060.html
Sent from the Sourceware - binutils list mailing list archive at Nabble.com.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]