<div dir="ltr">Indeed, thanks Greg. It dawned on my 1 min after I sent my post that I failed to change my compile flags. Red-faced Duh. But thanks for the additional info!</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 21, 2018 at 11:34 AM, Greg Clayton <span dir="ltr"><<a href="mailto:clayborg@gmail.com" target="_blank">clayborg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am guessing you don't have debug info enabled. Add "-g" to your command line when compiling. Or enable debug info in the Xcode settings.<br>
<br>
On Mac, debug info is contained in the .o files. The main executable doesn't have any debug info, but it has a debug map that tells LLDB how to link the debug info on the fly. Additionally, you can create a dSYM file which links the DWARF from all .o files into a single dSYM bundle (directory that contains the DWARF inside). This file will usually appear in the output of "image list pc-nb" for you program. <br>
<br>
In we have only DWARF in the .o files we will see just the executable in the output of "image list":<br>
<br>
$ lldb a.out<br>
(lldb) image list a.out<br>
[ 0] CB611ED7-8C13-337A-813A-<wbr>6B3D0CB194C2 0x0000000100000000 /Users/gclayton/Documents/src/<wbr>args/a.out <br>
(lldb) <br>
<br>
<br>
If we dump the symbol table for "a.out" we can see the debug map that points to the .o file where the symbol "Type" is set to "ObjectFile":<br>
<br>
(lldb) image dump symtab a.out <br>
Symtab, file = /Users/gclayton/Documents/src/<wbr>args/a.out, num_symbols = 8:<br>
Debug symbol<br>
|Synthetic symbol<br>
||Externally Visible<br>
|||<br>
Index UserID DSX Type File Address/Value Load Address Size Flags Name<br>
------- ------ --- --------------- ------------------ ------------------ ------------------ ---------- ------------------------------<wbr>----<br>
[ 0] 0 D SourceFile 0x0000000000000000 Sibling -> [ 5] 0x00640000 /Users/gclayton/Documents/src/<wbr>args/main.cpp<br>
[ 1] 2 D ObjectFile 0x000000005b16fec0 0x0000000000000000 0x00660001 /Users/gclayton/Documents/src/<wbr>args/main.o<br>
[ 2] 4 D X Code 0x0000000100000ee0 0x0000000000000040 0x000f0000 use_callback(float (*)(int, float))<br>
[ 3] 8 D X Code 0x0000000100000f20 0x0000000000000020 0x000f0000 MultiplyCallback(int, float)<br>
[ 4] 12 D X Code 0x0000000100000f40 0x000000000000002d 0x000f0000 main<br>
[ 5] 18 X Data 0x0000000100000000 0x0000000000000ee0 0x000f0010 _mh_execute_header<br>
[ 6] 20 Trampoline 0x0000000100000f6e 0x0000000000000006 0x00010200 printf<br>
[ 7] 21 X Undefined 0x0000000000000000 0x0000000000000000 0x00010200 dyld_stub_binder<br>
(lldb) <br>
<br>
<br>
We can see that symbol with index 1 is a ObjectFile symbol. If you have ObjectFile symbols and you still are not seeing file and line info, then make sure that the path to the .o file is still valid and also look for DWARF sections in that .o file:<br>
<br>
(lldb) file /Users/gclayton/Documents/src/<wbr>args/main.o<br>
Current executable set to '/Users/gclayton/Documents/<wbr>src/args/main.o' (x86_64).<br>
(lldb) image dump sections<br>
Dumping sections for 1 modules.<br>
Sections for '/Users/gclayton/Documents/<wbr>src/args/main.o' (x86_64):<br>
SectID Type File Address Perm File Off. File Size Flags Section Name<br>
---------- ---------------- ------------------------------<wbr>--------- ---- ---------- ---------- ---------- ----------------------------<br>
0x00000100 container [0x0000000000000000-<wbr>0x00000000000005b0) rwx 0x000005e0 0x000005b0 0x00000000 main.o.__TEXT<br>
0x00000001 code [0x0000000000000000-<wbr>0x000000000000008d) rwx 0x000005e0 0x0000008d 0x80000400 main.o.__TEXT.__text<br>
0x00000002 data-4-byte [0x0000000000000090-<wbr>0x0000000000000094) rwx 0x00000670 0x00000004 0x00000003 main.o.__TEXT.__literal4<br>
0x00000003 data-cstr [0x0000000000000094-<wbr>0x00000000000000aa) rwx 0x00000674 0x00000016 0x00000002 main.o.__TEXT.__cstring<br>
0x0000000f eh-frame [0x0000000000000520-<wbr>0x00000000000005b0) rwx 0x00000b00 0x00000090 0x6800000b main.o.__TEXT.__eh_frame<br>
0x00000200 container [0x00000000000000aa-<wbr>0x0000000000000613) rwx 0x0000068a 0x00000569 0x00000000 main.o.__DWARF<br>
0x00000004 dwarf-str [0x00000000000000aa-<wbr>0x0000000000000186) rwx 0x0000068a 0x000000dc 0x02000000 main.o.__DWARF.__debug_str<br>
0x00000005 dwarf-loc rwx 0x00000766 0x00000000 0x02000000 main.o.__DWARF.__debug_loc<br>
0x00000006 dwarf-abbrev [0x0000000000000186-<wbr>0x000000000000021e) rwx 0x00000766 0x00000098 0x02000000 main.o.__DWARF.__debug_abbrev<br>
0x00000007 dwarf-info [0x000000000000021e-<wbr>0x0000000000000325) rwx 0x000007fe 0x00000107 0x02000000 main.o.__DWARF.__debug_info<br>
0x00000008 dwarf-ranges rwx 0x00000905 0x00000000 0x02000000 main.o.__DWARF.__debug_ranges<br>
0x00000009 dwarf-macinfo [0x0000000000000325-<wbr>0x0000000000000326) rwx 0x00000905 0x00000001 0x02000000 main.o.__DWARF.__debug_macinfo<br>
0x0000000a apple-names [0x0000000000000326-<wbr>0x00000000000003d2) rwx 0x00000906 0x000000ac 0x02000000 main.o.__DWARF.__apple_names<br>
0x0000000b apple-objc [0x00000000000003d2-<wbr>0x00000000000003f6) rwx 0x000009b2 0x00000024 0x02000000 main.o.__DWARF.__apple_objc<br>
0x0000000c apple-namespaces [0x00000000000003f6-<wbr>0x000000000000041a) rwx 0x000009d6 0x00000024 0x02000000 main.o.__DWARF.__apple_<wbr>namespac<br>
0x0000000d apple-types [0x000000000000041a-<wbr>0x00000000000004be) rwx 0x000009fa 0x000000a4 0x02000000 main.o.__DWARF.__apple_types<br>
0x00000010 dwarf-line [0x00000000000005b0-<wbr>0x0000000000000613) rwx 0x00000b90 0x00000063 0x02000000 main.o.__DWARF.__debug_line<br>
0x00000300 container [0x00000000000004c0-<wbr>0x0000000000000520) rwx 0x00000aa0 0x00000060 0x00000000 main.o.__LD<br>
0x0000000e regular [0x00000000000004c0-<wbr>0x0000000000000520) rwx 0x00000aa0 0x00000060 0x02000000 main.o.__LD.__compact_unwind<br>
<br>
You want to make sure you see sections in the "__DWARF" segment. Above we can see we have __DWARF.__debug_info, __DWARF.__debug_line, __DWARF.__debug_str and __DWARF.__debug_abbrev. This indicates you have debug info.<br>
<br>
If we create a dSYM file for a.out:<br>
<br>
$ dsymutil a.out <br>
$ lldb a.out <br>
(lldb) target create "a.out"<br>
Current executable set to 'a.out' (x86_64).<br>
(lldb) image list a.out<br>
[ 0] CB611ED7-8C13-337A-813A-<wbr>6B3D0CB194C2 0x0000000100000000 /Users/gclayton/Documents/src/<wbr>args/a.out <br>
/Users/gclayton/Documents/src/<wbr>args/a.out.dSYM/Contents/<wbr>Resources/DWARF/a.out<br>
<br>
We can see that we have a dSYM file associate with a.out. LLDB will combine these two files into a single cohesive view and the sections for __DWARF will be included in the section list for "a.out":<br>
<br>
(lldb) image dump sections a.out <br>
Sections for '/Users/gclayton/Documents/<wbr>src/args/a.out' (x86_64):<br>
SectID Type File Address Perm File Off. File Size Flags Section Name<br>
---------- ---------------- ------------------------------<wbr>--------- ---- ---------- ---------- ---------- ----------------------------<br>
0x00000100 container [0x0000000000000000-<wbr>0x0000000100000000) --- 0x00000000 0x00000000 0x00000000 a.out.__PAGEZERO<br>
0x00000200 container [0x0000000100000000-<wbr>0x0000000100001000) r-x 0x00000000 0x00001000 0x00000000 a.out.__TEXT<br>
0x00000001 code [0x0000000100000ee0-<wbr>0x0000000100000f6d) r-x 0x00000ee0 0x0000008d 0x80000400 a.out.__TEXT.__text<br>
0x00000002 code [0x0000000100000f6e-<wbr>0x0000000100000f74) r-x 0x00000f6e 0x00000006 0x80000408 a.out.__TEXT.__stubs<br>
0x00000003 code [0x0000000100000f74-<wbr>0x0000000100000f8e) r-x 0x00000f74 0x0000001a 0x80000400 a.out.__TEXT.__stub_helper<br>
0x00000004 regular [0x0000000100000f90-<wbr>0x0000000100000f94) r-x 0x00000f90 0x00000004 0x00000000 a.out.__TEXT.__const<br>
0x00000005 data-cstr [0x0000000100000f94-<wbr>0x0000000100000faa) r-x 0x00000f94 0x00000016 0x00000002 a.out.__TEXT.__cstring<br>
0x00000006 compact-unwind [0x0000000100000fac-<wbr>0x0000000100000ff4) r-x 0x00000fac 0x00000048 0x00000000 a.out.__TEXT.__unwind_info<br>
0x00000300 container [0x0000000100001000-<wbr>0x0000000100002000) rw- 0x00001000 0x00001000 0x00000000 a.out.__DATA<br>
0x00000007 data-ptrs [0x0000000100001000-<wbr>0x0000000100001010) rw- 0x00001000 0x00000010 0x00000006 a.out.__DATA.__nl_symbol_ptr<br>
0x00000008 data-ptrs [0x0000000100001010-<wbr>0x0000000100001018) rw- 0x00001010 0x00000008 0x00000007 a.out.__DATA.__la_symbol_ptr<br>
0x00000400 container [0x0000000100002000-<wbr>0x0000000100003000) r-- 0x00002000 0x00000308 0x00000000 a.out.__LINKEDIT<br>
0x00000200 container [0x0000000100003000-<wbr>0x0000000100004000) rw- 0x00002000 0x000005a9 0x00000000 a.out.__DWARF<br>
0x00000001 dwarf-line [0x0000000100003000-<wbr>0x000000010000307c) rw- 0x00002000 0x0000007c 0x00000000 a.out.__DWARF.__debug_line<br>
0x00000002 dwarf-pubnames [0x000000010000307c-<wbr>0x00000001000030f3) rw- 0x0000207c 0x00000077 0x00000000 a.out.__DWARF.__debug_pubnames<br>
0x00000003 dwarf-pubtypes [0x00000001000030f3-<wbr>0x0000000100003131) rw- 0x000020f3 0x0000003e 0x00000000 a.out.__DWARF.__debug_pubtypes<br>
0x00000004 dwarf-aranges [0x0000000100003131-<wbr>0x0000000100003181) rw- 0x00002131 0x00000050 0x00000000 a.out.__DWARF.__debug_aranges<br>
0x00000005 dwarf-info [0x0000000100003181-<wbr>0x0000000100003288) rw- 0x00002181 0x00000107 0x00000000 a.out.__DWARF.__debug_info<br>
0x00000006 dwarf-abbrev [0x0000000100003288-<wbr>0x0000000100003320) rw- 0x00002288 0x00000098 0x00000000 a.out.__DWARF.__debug_abbrev<br>
0x00000007 dwarf-str [0x0000000100003320-<wbr>0x00000001000033fd) rw- 0x00002320 0x000000dd 0x00000000 a.out.__DWARF.__debug_str<br>
0x00000008 apple-names [0x00000001000033fd-<wbr>0x00000001000034a9) rw- 0x000023fd 0x000000ac 0x00000000 a.out.__DWARF.__apple_names<br>
0x00000009 apple-namespaces [0x00000001000034a9-<wbr>0x00000001000034cd) rw- 0x000024a9 0x00000024 0x00000000 a.out.__DWARF.__apple_namespac<br>
0x0000000a apple-types [0x00000001000034cd-<wbr>0x0000000100003585) rw- 0x000024cd 0x000000b8 0x00000000 a.out.__DWARF.__apple_types<br>
0x0000000b apple-objc [0x0000000100003585-<wbr>0x00000001000035a9) rw- 0x00002585 0x00000024 0x00000000 a.out.__DWARF.__apple_objc<br>
(lldb) <br>
<br>
Above we can see we have __DWARF.__debug_info, __DWARF.__debug_line, __DWARF.__debug_str and __DWARF.__debug_abbrev. This indicates you have debug info.<br>
<br>
<br>
So to sum up: you need debug info in order to get source file and line information when debugging. This is done by specifying -g on the command line. The above steps help you to verify if you have debug info in your executable or shared library (replace "a.out" above with the basename of the executable you want to check for debug info).<br>
<br>
Greg Clayton<br>
<div><div class="h5"><br>
> On Jun 21, 2018, at 8:18 AM, Randy Heiland via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> I cannot figure how to get a backtrace with filenames/line #s. Suggestions? (And if this list is not the proper one to ask such questions, please redirect me)<br>
> <br>
> On OSX with:<br>
> $ lldb --version<br>
> lldb-900.0.64<br>
> Swift-4.0<br>
> <br>
> For example:<br>
> (lldb) bt<br>
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT<br>
> frame #0: 0x00000001001e7d42 libsystem_kernel.dylib`__<wbr>pthread_kill + 10<br>
> frame #1: 0x00007fffc4d91457 libsystem_pthread.dylib`<wbr>pthread_kill + 90<br>
> frame #2: 0x00007fffc4c09420 libsystem_c.dylib`abort + 129<br>
> frame #3: 0x00007fffc4cf8fe7 libsystem_malloc.dylib`free + 530<br>
> frame #4: 0x0000000100017138 pc-nb`BioFVM::<wbr>Microenvironment::compute_<wbr>gradient_vector(int) + 472<br>
> frame #5: 0x00000001000174ca pc-nb`BioFVM::<wbr>Microenvironment::gradient_<wbr>vector(int) + 42<br>
> frame #6: 0x0000000100021bc1 pc-nb`BioFVM::Basic_Agent::<wbr>nearest_gradient(int) + 17<br>
> frame #7: 0x0000000100069ccc pc-nb`chemotaxis_function(<wbr>PhysiCell::Cell*, PhysiCell::Phenotype&, double) + 364<br>
> frame #8: 0x0000000100054ecc pc-nb`PhysiCell::Cell::update_<wbr>motility_vector(double) + 284<br>
> frame #9: 0x0000000100053262 pc-nb`PhysiCell::standard_<wbr>update_cell_velocity(<wbr>PhysiCell::Cell*, PhysiCell::Phenotype&, double) + 818<br>
> frame #10: 0x0000000100051053 pc-nb`.omp_outlined..7 + 211<br>
> frame #11: 0x0000000100186043 libomp.dylib`__kmp_invoke_<wbr>microtask + 147<br>
> frame #12: 0x000000010015bfff libomp.dylib`__kmp_invoke_<wbr>task_func + 156<br>
> frame #13: 0x000000010015943c libomp.dylib`__kmp_fork_call + 5961<br>
> frame #14: 0x000000010015075e libomp.dylib`__kmpc_fork_call + 192<br>
> * frame #15: 0x0000000100050b0c pc-nb`PhysiCell::Cell_<wbr>Container::update_all_cells(<wbr>double, double, double, double) + 780<br>
> frame #16: 0x0000000100071a54 pc-nb`main + 2516<br>
> frame #17: 0x00000001001c5235 libdyld.dylib`start + 1<br>
> frame #18: 0x00000001001c5235 libdyld.dylib`start + 1<br>
> <br>
> It would seem that my default formatting would have this:<br>
> (lldb) settings show frame-format<br>
> frame-format (format-string) = "frame #${frame.index}: ${frame.pc}{ ${module.file.basename}{`${<wbr>function.name-with-args}{${<wbr>frame.no-debug}${function.pc-<wbr>offset}}}}{ at ${line.file.basename}:${line.<wbr>number}}{${function.is-<wbr>optimized} [opt]}\n"<br>
> <br>
> Thanks!<br>
> -Randy<br>
</div></div>> ______________________________<wbr>_________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br></div>