Debugging an externally compiled executable

I have the exact same problem like you do, I'm on MacOSX 10.11.4 and my Clion version is 2016.1.

If I use LLDB debugger my breakpoints would not stop in most of the cases. My programme would just finish and exit without stopping any where. Once I change the debugger to GDB everything works just fine.

GDB on OS X requires additional adjustments, do they help?

GDB work fine. So no, it's not helpful at all.

My bad, apologies for being inattentive.

The problem might be related to the case sensitivity of the source files, which are passed to the compiler and recorded in the debug info (CPP-6598).

Do the real file names and file names in the build scripts match?

No need to apologize, i was a bit rude in that previous answer.

My file system is case sensitive (i know this is unusual for macosx and I should have mentionned that in the original post). So a case mismatch anywhere would lead to obvious and serious problems.

I checked, just in case and the cases matches.

This is the result of "breakpoint list" command for one of the breakpoints ;

14: file = '/Users/Alex/Documents/qcm3/ImpuritySolver/Matrixgen/MatrixGen_Test.cpp', line = 503, exact_match = 0, locations = 0 (pending)

The path to the file and line number in the file is correct just the same as the 13 preceding ones. The values of "exact_match" and "locations" are also the same for all breakpoints.

Thank you for your help Anton.

Alexandre, what is the path to MatrixGen_Test.cpp in the output of "image dump line-table MatrixGen_Test.cpp"?

Sorry, it took me forever.

It is  "/Users/Alex/Documents/qcm3/ImpuritySolver/Matrixgen/build/../MatrixGen_Test.cpp".

I guess the step back in the path could be the source of the problem.

Could you please check whether the issue is still reproducible with CLion 2016.2.1? There were some fixes since then.

Yeah, i am using that version. No changes at all as far as what i have reported is concerned.

OK. You are correct, the problem is caused by difference in the path. Do you know where "build/../" might come from? Do you use any symlinks?

There's no symlinks interfering there.

With the step back, it's the information as it is given by the debug info in the MatrixGen_Test.cpp.o object file. As we can see in the begining of the debug info it contains:

BS_Utest@exe $ dwarfdump MatrixGen_Test.cpp.o
----------------------------------------------------------------------
 File: MatrixGen_Test.cpp.o (x86_64)
----------------------------------------------------------------------
.debug_info contents:

0x00000000: Compile Unit: length = 0x000b8e69  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x000b8e6d)

0x0000000b: TAG_compile_unit [1] *
             AT_producer( "clang version 3.7.0 (tags/RELEASE_370/final)" )
             AT_language( DW_LANG_C_plus_plus )
             AT_name( "../MatrixGen_Test.cpp" )
             AT_stmt_list( 0x00000000 )
             AT_comp_dir( "/Users/Alex/Documents/qcm3/ImpuritySolver/Matrixgen/build" )

When using an executable build with the cmake in Clion, AT_name contain an absolute path. This mean that CLion supply the absolute path to the source file when building every single object file, that's why there's no problem when using Clion's Cmake.

As a work around i can modify my external build system so it uses absolute paths too.

I would prefer if Clion set breakpoint using relative paths (add an option somewhere?). This mean that when calling "br list" a breakpoint set in MatrixGen_Test.cpp would read

file = 'MatrixGen_Test.cpp', line = 970, exact_match = 0, locations = 1, resolved = 1, hit count = 0

instead of

file = '/Users/Alex/Documents/qcm3/ImpuritySolver/Matrixgen/MatrixGen_Test.cpp', line = 970, exact_match = 0, locations = 0 (pending)

Thank you Vyacheslav, the command "image dump line-table" did contain the missing information needed to resolve this puzzle.

The reason why GDB works without a hitch is that it resolve the paths of the source files when it read the debug info, instead of just concatenating AT_comp_dir and AT_name. Really, LLDB should do that too.

Hello,

I have a C++ code which I edit through CLion, but I don't build it using CLion. I'd like to debug it. Up until now I used "Attach to Process..." option in "Run" menu. Is there a configuration allowing such debugging ?

Thanks,

Gidi