2

I know you can build an application on Linux without -g, and then later debug a corefile from the application with a binary from the same code but built with -g (all other options being the same). If the nm output is identical then the symbols match up and you can effectively analyze a corefile.

However, while I have been successful doing this on Linux, I have not been able to get this to work for Solaris. I build with -xO4, so maybe the optimization level is not supported by -g? I also tried -g0 and that did not work either. The nm file is vastly different. I am also building with -xs. Should I build without -xs instead?

Before I try to analyze this further, has anyone been able to get this to work?

To be clear, this is an issue of building and using debug libraries after the fact. This is possible with Linux if you build with -g and everything else the same (-O3), but I cannot get it to work with our Solaris build, which uses -xO4.

This is not an issue of getting the system libraries to match up, because I already have a copy of the system libraries from our customer and they match up fine. It is our libraries that do not match up when built with debug symbols (-g0). When we don't use -g0 our symbols match up fine but we cannot debug into the source level and get local and global variable values.

AdamSkwersky
  • 76
  • 5
  • What tool(s) and what version(s) of them are you using to debug? I've had success debugging core files on Solaris compiled with `-fast -g0` in the past. What errors are you seeing? `-xs` shouldn't matter with recent versions of the Studio compiler because the symbols use dwarf format in later versions and dwarf debug symbols are in the executable anyway. – Andrew Henle Apr 25 '16 at 21:15
  • The production code wasn't built with -g or -g0. I am trying to debug the corefile with new libraries built with same -xO with -g0 added, but no luck. The compiler version is: CC: Sun C++ 5.6 Patch 117549-08 2007/03/27 I know it is pretty old. – AdamSkwersky Apr 27 '16 at 15:40
  • Are you debugging on a different machine than the core file was created on? If so, shared objects used by the executable have to be identical on both systems, otherwise the addresses in the core file will be nonsensical. Or you can copy the relevant shared objects to the debug server and set up `dbx` properly to use the copied shared objects from the core-generating machine. – Andrew Henle Apr 27 '16 at 17:43
  • @andrew-henle - That is not the problem. Please re-read the question, which I've added additional content to. This is not an issue of getting system libraries to match up. I have copies of the customer system libraries and they match up fine. Everything matches up fine if I use their system libraries and our libraries. The problem is rebuilding our libraries with -g0 and trying to debug the core file with those. This works with Linux. I can get the symbols to match up in Linux because all the debug info does not affect the location of the symbols in the debug libraries. – AdamSkwersky Apr 28 '16 at 20:48
  • @adnrew-henle continued: Maybe it is that the debug format is different for the Solaris compiler and it is moving the symbols around rather than keeping them in the same place. – AdamSkwersky Apr 28 '16 at 20:48

0 Answers0