Getting Debug Symbols on MacOS - Forum Open Cascade Technology

Firstname Lastname
Fri, 08/30/2024 - 00:51

Forums:

I'm trying to build OpenCASCADE with debug symbols on MacOS so that I can understand backtraces produced in LLDB.

I've successfully built and installed OpenCASCADE with CMake. I'm building with the system toolchain: Apple Clang 14.0.3. Before building, I set the BUILD_WITH_DEBUG CMake cache variable to ON and the CMAKE_BUILD_TYPE CMake cache variable to Debug. I've successfully linked my application against OpenCASCADE's dynamic libraries and my application runs.

However, there is some bug in either my application or OpenCASCADE that causes a segfault. To debug, I start up LLDB with my executable. I let my executable run in the debugger and I get the result:

As you can see, additional debug information (due to the BUILD_WITH_DEBUG CMake cache variable) is being produced for OpenCASCADE's BRepOffsetAPI_MakePipe() function. But when I try to move up the stack frames to see what is being called within OpenCASCADE's dynamic libraries, LLDB will only dump assembly, not symbols from the C++ source. So it appears as though LLDB isn't able to find the debug symbols for the OpenCASCADE's dynamic libraries. Anyone have any ideas?

PS: I checked that the -g flag is passed to Clang when building the various OpenCASCADE dynamic libraries and that the size of OpenCASCADE's dynamic libraries grow significantly when I set CMAKE_BUILD_TYPE to Debug. I also used otool to check that the object files used to produce OpenCASCADE's dynamic libraries contain DWARF sections. As such, I'm fairly confident that OpenCASCADE's dynamic libraries do contain debug maps. I'm not sure where the debug maps are located in OpenCASCADE's dynamic libraries, so I haven't been able to use otool to check that the dynamic libraries contain the correct paths to the object files holding the DWARF debug info. Maybe the debug maps in OpenCASCADE's dynamic libraries don't contain the correct paths to the object files? This is what I'm currently thinking the problem is. LLDB is telling me that OpenCASCADE's dynamic libraries don't have any corresponding compile units, so this seems like the most plausible explanation.

Firstname Lastname
Fri, 08/30/2024 - 06:21

I figured out the problem. It turns out that the dynamic libraries produced for OpenCASCADE, even with all the necessary CMake cache variables set to the correct values (i.e. BUILD_WITH_DEBUG=ON and CMAKE_BUILD_TYPE=Debug), have their debug symbols stripped. This happens in the file "adm/cmake/occt_defs_flags.cmake" around line 175. Notably, the object files are produced with the requisite DWARF debug symbols, which led me astray. I haven't tested if this bug also affects Linux and Windows builds, but I suspect that it does.

I filed this as bug #0033812 in the Mantis Issue Tracker.

gkv311 n
Fri, 08/30/2024 - 09:31

It looks like a regression since the patch for #0031606 (solving building issues on Android). Could you try replacing CMAKE_SHARED_LINKER_FLAGS with CMAKE_SHARED_LINKER_FLAGS_RELEASE at this line?

  # Optimize size of binaries
-  set (CMAKE_SHARED_LINKER_FLAGS "-Wl,-s ${CMAKE_SHARED_LINKER_FLAGS}")
+  set (CMAKE_SHARED_LINKER_FLAGS_RELEASE "-Wl,-s ${CMAKE_SHARED_LINKER_FLAGS_RELEASE}")

The issue doesn't affect Linux (GCC) or Windows (MSVC), as this flag is passed accidentally only to Clang linker in debug builds.

Firstname Lastname
Fri, 08/30/2024 - 15:39

Yes, that patch does fix the problem.

Dmitrii Pasukhin
Fri, 08/30/2024 - 16:15

I will check with clang on Win and Debian. After that patch will be integrated into latest master.

Thank you a lot for the fix and checking!

Best regards, Dmitrii.