Search code examples
c++linuxbacktrackingbacktraceline-numbers

Is it possible to use addr2line with application compiled with release optimization arguments?

So I've got a backtrace

Exit with signal 11 at 2013-12-28_14:28:58.000000
/opt/s3ds/App(_Z7handlers+0x52) [0x5de322]
/lib/libc.so.6(+0x32230) [0x7f6ab9b3a230]
/opt/s3ds/App(_ZN17Service17Controller5frameERKf+0x505) [0x5a6b85]
/opt/s3ds/App(_ZN17Service15Cloud10updateEf+0x1de) [0x58642e]
/opt/s3ds/App(_ZN17Manager6updateEf+0x21b) [0x59194b]
/opt/s3ds/App(_ZN7Manager3runEv+0xd2) [0x604fa2]
/opt/s3ds/App() [0x62bfea]
/lib/libpthread.so.0(+0x68ca) [0x7f6abb0048ca]
/lib/libc.so.6(clone+0x6d) [0x7f6ab9bd7b6d]

I've compiled my application with next arguments:

            -std=c++11 -fpermissive -m64 -g -rdynamic -mtune=native -flto -O3

So it is a release build with some minimal debug information.

I wonder if it is possible to use addr2line to get any line number from such optimized build?

I tried example shown here yet I get ??:0 like:

$ addr2line -e ./App 0x62bfea
??:0

for all adresses in []. I know tha functions in that trace from Service::Controller::frame up to Manager::run (and probably even that lambda /opt/s3ds/App() [0x62bfea]) shall be in my app code (not in some library).

So Is it possible to get line numbers for production optimized code? Are there any additional compiler argiments required to get them?

Solution

  • It may be possible, but it might not amount to much.

    You have to understand that the very goal of optimizations is to alter the code to make it better (by some metric); and alteration means that the resulting code may not be meaningfully mapped to source code afterwards.

    Some examples:

    • Dead Code Elimination and the like will remove existing code, this mainly affect an attempt to place a breakpoint at a given source-line since there may not be code for that line
    • Common Sub-Expression Elimination will create new temporary variables out of the blue to compute a sub-expression only once; those sub-expressions may have originally appeared in multiple expressions spread throughout the source code so the new instructions belong to multiple lines... or none at all
    • Invariant Hoisting or Loop Rotation will change the order in which expressions are computed compared with the original source code so that you might see code executed at line 3 then 6 then 4, 5, 7...
    • Loop Unrolling will copy/paste the body of a loop multiple times

    And of course, those are local to a function, you also to have to account for

    • Function Inlining will copy paste the body of a function at the call site
    • Function Merging will take two different functions and remove one of them, forwarding its calls to the other (because they have the same behavior, of course)

    After all that, is it even meaningful to try and reason in terms of source code ? No, not really. And of course I did not even account for the fact that all those transformations occurred on the Intermediate Representation and that the final emission of assembly code will scramble things even further (Strength Reduction, yeah!).

    Honestly, even if addr2line gives you some line, I would doubt its result... and then what is the point of asking in the first place ?