Debugging an externally compiled executable

I am attempting to run the debugger on a file compile by a regular makefile. To do so i open the project with clion and added a compilation target which has this executable and no compilation rule.


If i attempt to debug it with the bundled lldb, all the breakpoints that i set are ignored. I know the debugger does attach to the executable, because if i introduce an error that will cause a SIGABRT, the will stop ande give me the state of the program at the error and clion shows the line at which the error is as the cause.

If i use the bundled gdb instead, everything is fine. Is there some subtle difference between lldb and gdb that could cause such a problem, or am i dealing with a bug?

I am on MacOsX 10.11.2

Thank you all.

12 comments
Comment actions Permalink

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.

1
Comment actions Permalink

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

0
Comment actions Permalink

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

0
Comment actions Permalink

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?

 

1
Comment actions Permalink

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.

0
Comment actions Permalink

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

1
Comment actions Permalink

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.

0
Comment actions Permalink

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

0
Comment actions Permalink

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

0
Comment actions Permalink

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?

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0

Please sign in to leave a comment.