Support #7580
Can't debug with the debug builds of art and externals on Mac OSX
0%
Description
Hi - I've been playing with the OSX debugger (lldb) because it's really nice. I've been trying to debug some code in Geant4 and learning this is not as simple as it should be. I've learned that though we supply debug builds of art and the art externals, they can't actually be used for debugging. The problem is that when you build on the Mac, all of the debugging information goes into the .o files, not the executables nor the .dyld's. Chris Jones says this is done for security, so that you can't reverse-engineer Apple's software. You can see this for yourself... If you take a debug dyld or executable and do,
nm -pa <exe or dyld file> | grep 'OSO'
you will see references to the .o files. If you have the .o files, you can then do,
dwarfdump <.o file>
and then you'll see all of the debugging information, including references to the source files.
Without the .o files, and of course the source files, the debugger can only show you assembly code - not the source even if you have the source. Furthermore, lldb will crash if you try to look at an object where part of it is defined in your code and part is defined in a dyld (e.g. inherited) and the dyld's .o files don't exist.
So the upshot is that if you want to debug art or geant or something like that, you need to build it all yourself and keep the .o files around. To make matters worse, the references to the .o files in the dyld/executable and to the source code are all absolute paths. There is a way to relocate the source code and have the debugger still find it, but I don't know if there's a way to relocate the .o files.
I've looked to see how other software deals with this - like Qt. The Qt documentation states that while they supply debug libraries of their software for the Mac, if you actually want to debug Qt you need to download the source and build it all yourself. Then you can debug.
I don't have a good solution for any of this - and I don't think there is one. We probably don't want to be shipping non-relocatable .o files. I think there is a way to extract the debug information from the .o's into a dSYM file, but I haven't looked carefully at that and probably won't. So perhaps this ticket is just FYI unless someone has an idea. This is kind of a shame, because debugging in Xcode is really nice - almost fun. Boo on Apple! -- Adam
History
#1 Updated by Christopher Green about 6 years ago
- Category set to Build System
After doing some reading, it looks like we can generate the .dSYM
files as part of the build process using POST BUILD
custom commands for executables and libraries. It looks like I would use information presented at https://github.com/OPM/opm-benchmarks/blob/master/cmake/Modules/UseDebugSymbols.cmake to implement this in cetbuildtools
(and wherever necessary). The custom command must be added as a POST BUILD
command for each library and executable target for whatever package, and the .dSYM
files must be shipped with the built package. I am not sure of the correct location for the .dSYM
files, but my first guess would be the same directory (lib
or bin
) as the executable or library for which it was generated.
#2 Updated by Kyle Knoepfel about 6 years ago
- Status changed from New to Feedback
Please try using gdb
, which is available on scisoft
at:
http://scisoft.fnal.gov/scisoft/packages/gdb/v7_8/
You may need to use sudo gdb
. If you're trying to use gdb
within Xcode
, we would be interested in hearing about your experience and any limitations we need to work on. It is not clear to us that lldb
will be able to understand the gcc
debug output. If you're interested in trying to create .dSYM
files as mentioned in the previous comment, we'd like to know your experience.
#3 Updated by Kyle Knoepfel almost 6 years ago
- Target version set to 521
#4 Updated by Kyle Knoepfel about 3 years ago
- Target version deleted (
521)