I have a stack trace from an application that was built and run on CentOS 5.4. The application was built without debug so there are no symbols or line numbers in the stack trace, but only addresses, like so:
/opt/app/bin/myApp [0x22ec09e]
/opt/app/bin/myApp [0x1fcdf31]
/opt/app/bin/myApp [0x22ebbcb]
...
I also have the same application, but built with debug (-g). So I am able to open this binary with gdb and find out the corresponding source files, function names and line numbers corresponding to these addresses.
My question is, having this binary built with debug on CentOS 5.4, does it matter on which OS I am using gdb to resolve the symbols? If I open it with gdb on CentOS 5.4 and use info line or list, could the result differ from when doing the same on say Fedora 16? I have done a few tests doing this on CentOS 5.4 and Fedora 16 which indicates that there is no difference. However, can I trust that this is always so or could I one day find out that there could be differences under certain circumstances?
Notes: Application was written in C++ and built with g++. Please let me know if any additional information is needed to answer this question.
does it matter on which OS I am using gdb to resolve the symbols?
No: the mapping of addresses to line numbers is fixed at binary link time. Once the binary is linked, you can perform the mapping on any OS you wish.
I also have the same application, but built with debug (-g).
Note that the mapping does change depending on optimization flags you used. This would work:
# original application build
g++ -O2 foo.cc bar.cc -o app
# same with debug symbols:
g++ -O2 -g foo.cc bar.cc -o app_g
This would not work (symbols between app and app_g2 will not match):
g++ -g foo.cc bar.cc -o app_g2