getting filename/line #

Subprojects LLDB
1

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)

On OSX with:
$ lldb --version
lldb-900.0.64
Swift-4.0

For example:

(lldb) bt

  • thread #1, queue = ‘com.apple.main-thread’, stop reason = signal SIGABRT
    frame #0: 0x00000001001e7d42 libsystem_kernel.dylib__pthread_kill + 10 frame #1: 0x00007fffc4d91457 libsystem_pthread.dylibpthread_kill + 90
    frame #2: 0x00007fffc4c09420 libsystem_c.dylibabort + 129 frame #3: 0x00007fffc4cf8fe7 libsystem_malloc.dylibfree + 530
    frame #4: 0x0000000100017138 pc-nbBioFVM::Microenvironment::compute_gradient_vector(int) + 472 frame #5: 0x00000001000174ca pc-nbBioFVM::Microenvironment::gradient_vector(int) + 42
    frame #6: 0x0000000100021bc1 pc-nbBioFVM::Basic_Agent::nearest_gradient(int) + 17 frame #7: 0x0000000100069ccc pc-nbchemotaxis_function(PhysiCell::Cell*, PhysiCell::Phenotype&, double) + 364
    frame #8: 0x0000000100054ecc pc-nbPhysiCell::Cell::update_motility_vector(double) + 284 frame #9: 0x0000000100053262 pc-nbPhysiCell::standard_update_cell_velocity(PhysiCell::Cell*, PhysiCell::Phenotype&, double) + 818
    frame #10: 0x0000000100051053 pc-nb.omp_outlined..7 + 211 frame #11: 0x0000000100186043 libomp.dylib__kmp_invoke_microtask + 147
    frame #12: 0x000000010015bfff libomp.dylib__kmp_invoke_task_func + 156 frame #13: 0x000000010015943c libomp.dylib__kmp_fork_call + 5961
    frame #14: 0x000000010015075e libomp.dylib`__kmpc_fork_call + 192
  • frame #15: 0x0000000100050b0c pc-nbPhysiCell::Cell_Container::update_all_cells(double, double, double, double) + 780 frame #16: 0x0000000100071a54 pc-nbmain + 2516
    frame #17: 0x00000001001c5235 libdyld.dylibstart + 1 frame #18: 0x00000001001c5235 libdyld.dylibstart + 1

It would seem that my default formatting would have this:
(lldb) settings show frame-format
frame-format (format-string) = “frame #${frame.index}: ${frame.pc}{ ${module.file.basename}{`${function.name-with-args}{${frame.no-debug}${function.pc-offset}}}}{ at ${line.file.basename}:${line.number}}{${function.is-optimized} [opt]}\n”

Thanks!
-Randy

2

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.

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.

In we have only DWARF in the .o files we will see just the executable in the output of "image list":

$ lldb a.out
(lldb) image list a.out
[ 0] CB611ED7-8C13-337A-813A-6B3D0CB194C2 0x0000000100000000 /Users/gclayton/Documents/src/args/a.out
(lldb)

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":

(lldb) image dump symtab a.out
Symtab, file = /Users/gclayton/Documents/src/args/a.out, num_symbols = 8:
               Debug symbol
               >Synthetic symbol
               >>Externally Visible
               >>>
Index UserID DSX Type File Address/Value Load Address Size Flags Name
------- ------ --- --------------- ------------------ ------------------ ------------------ ---------- ----------------------------------
[ 0] 0 D SourceFile 0x0000000000000000 Sibling -> [ 5] 0x00640000 /Users/gclayton/Documents/src/args/main.cpp
[ 1] 2 D ObjectFile 0x000000005b16fec0 0x0000000000000000 0x00660001 /Users/gclayton/Documents/src/args/main.o
[ 2] 4 D X Code 0x0000000100000ee0 0x0000000000000040 0x000f0000 use_callback(float (*)(int, float))
[ 3] 8 D X Code 0x0000000100000f20 0x0000000000000020 0x000f0000 MultiplyCallback(int, float)
[ 4] 12 D X Code 0x0000000100000f40 0x000000000000002d 0x000f0000 main
[ 5] 18 X Data 0x0000000100000000 0x0000000000000ee0 0x000f0010 _mh_execute_header
[ 6] 20 Trampoline 0x0000000100000f6e 0x0000000000000006 0x00010200 printf
[ 7] 21 X Undefined 0x0000000000000000 0x0000000000000000 0x00010200 dyld_stub_binder
(lldb)

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:

(lldb) file /Users/gclayton/Documents/src/args/main.o
Current executable set to '/Users/gclayton/Documents/src/args/main.o' (x86_64).
(lldb) image dump sections
Dumping sections for 1 modules.
Sections for '/Users/gclayton/Documents/src/args/main.o' (x86_64):
  SectID Type File Address Perm File Off. File Size Flags Section Name
  ---------- ---------------- --------------------------------------- ---- ---------- ---------- ---------- ----------------------------
  0x00000100 container [0x0000000000000000-0x00000000000005b0) rwx 0x000005e0 0x000005b0 0x00000000 main.o.__TEXT
  0x00000001 code [0x0000000000000000-0x000000000000008d) rwx 0x000005e0 0x0000008d 0x80000400 main.o.__TEXT.__text
  0x00000002 data-4-byte [0x0000000000000090-0x0000000000000094) rwx 0x00000670 0x00000004 0x00000003 main.o.__TEXT.__literal4
  0x00000003 data-cstr [0x0000000000000094-0x00000000000000aa) rwx 0x00000674 0x00000016 0x00000002 main.o.__TEXT.__cstring
  0x0000000f eh-frame [0x0000000000000520-0x00000000000005b0) rwx 0x00000b00 0x00000090 0x6800000b main.o.__TEXT.__eh_frame
  0x00000200 container [0x00000000000000aa-0x0000000000000613) rwx 0x0000068a 0x00000569 0x00000000 main.o.__DWARF
  0x00000004 dwarf-str [0x00000000000000aa-0x0000000000000186) rwx 0x0000068a 0x000000dc 0x02000000 main.o.__DWARF.__debug_str
  0x00000005 dwarf-loc rwx 0x00000766 0x00000000 0x02000000 main.o.__DWARF.__debug_loc
  0x00000006 dwarf-abbrev [0x0000000000000186-0x000000000000021e) rwx 0x00000766 0x00000098 0x02000000 main.o.__DWARF.__debug_abbrev
  0x00000007 dwarf-info [0x000000000000021e-0x0000000000000325) rwx 0x000007fe 0x00000107 0x02000000 main.o.__DWARF.__debug_info
  0x00000008 dwarf-ranges rwx 0x00000905 0x00000000 0x02000000 main.o.__DWARF.__debug_ranges
  0x00000009 dwarf-macinfo [0x0000000000000325-0x0000000000000326) rwx 0x00000905 0x00000001 0x02000000 main.o.__DWARF.__debug_macinfo
  0x0000000a apple-names [0x0000000000000326-0x00000000000003d2) rwx 0x00000906 0x000000ac 0x02000000 main.o.__DWARF.__apple_names
  0x0000000b apple-objc [0x00000000000003d2-0x00000000000003f6) rwx 0x000009b2 0x00000024 0x02000000 main.o.__DWARF.__apple_objc
  0x0000000c apple-namespaces [0x00000000000003f6-0x000000000000041a) rwx 0x000009d6 0x00000024 0x02000000 main.o.__DWARF.__apple_namespac
  0x0000000d apple-types [0x000000000000041a-0x00000000000004be) rwx 0x000009fa 0x000000a4 0x02000000 main.o.__DWARF.__apple_types
  0x00000010 dwarf-line [0x00000000000005b0-0x0000000000000613) rwx 0x00000b90 0x00000063 0x02000000 main.o.__DWARF.__debug_line
  0x00000300 container [0x00000000000004c0-0x0000000000000520) rwx 0x00000aa0 0x00000060 0x00000000 main.o.__LD
  0x0000000e regular [0x00000000000004c0-0x0000000000000520) rwx 0x00000aa0 0x00000060 0x02000000 main.o.__LD.__compact_unwind

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.

If we create a dSYM file for a.out:

$ dsymutil a.out
$ lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) image list a.out
[ 0] CB611ED7-8C13-337A-813A-6B3D0CB194C2 0x0000000100000000 /Users/gclayton/Documents/src/args/a.out
      /Users/gclayton/Documents/src/args/a.out.dSYM/Contents/Resources/DWARF/a.out

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":

(lldb) image dump sections a.out
Sections for '/Users/gclayton/Documents/src/args/a.out' (x86_64):
  SectID Type File Address Perm File Off. File Size Flags Section Name
  ---------- ---------------- --------------------------------------- ---- ---------- ---------- ---------- ----------------------------
  0x00000100 container [0x0000000000000000-0x0000000100000000) --- 0x00000000 0x00000000 0x00000000 a.out.__PAGEZERO
  0x00000200 container [0x0000000100000000-0x0000000100001000) r-x 0x00000000 0x00001000 0x00000000 a.out.__TEXT
  0x00000001 code [0x0000000100000ee0-0x0000000100000f6d) r-x 0x00000ee0 0x0000008d 0x80000400 a.out.__TEXT.__text
  0x00000002 code [0x0000000100000f6e-0x0000000100000f74) r-x 0x00000f6e 0x00000006 0x80000408 a.out.__TEXT.__stubs
  0x00000003 code [0x0000000100000f74-0x0000000100000f8e) r-x 0x00000f74 0x0000001a 0x80000400 a.out.__TEXT.__stub_helper
  0x00000004 regular [0x0000000100000f90-0x0000000100000f94) r-x 0x00000f90 0x00000004 0x00000000 a.out.__TEXT.__const
  0x00000005 data-cstr [0x0000000100000f94-0x0000000100000faa) r-x 0x00000f94 0x00000016 0x00000002 a.out.__TEXT.__cstring
  0x00000006 compact-unwind [0x0000000100000fac-0x0000000100000ff4) r-x 0x00000fac 0x00000048 0x00000000 a.out.__TEXT.__unwind_info
  0x00000300 container [0x0000000100001000-0x0000000100002000) rw- 0x00001000 0x00001000 0x00000000 a.out.__DATA
  0x00000007 data-ptrs [0x0000000100001000-0x0000000100001010) rw- 0x00001000 0x00000010 0x00000006 a.out.__DATA.__nl_symbol_ptr
  0x00000008 data-ptrs [0x0000000100001010-0x0000000100001018) rw- 0x00001010 0x00000008 0x00000007 a.out.__DATA.__la_symbol_ptr
  0x00000400 container [0x0000000100002000-0x0000000100003000) r-- 0x00002000 0x00000308 0x00000000 a.out.__LINKEDIT
  0x00000200 container [0x0000000100003000-0x0000000100004000) rw- 0x00002000 0x000005a9 0x00000000 a.out.__DWARF
  0x00000001 dwarf-line [0x0000000100003000-0x000000010000307c) rw- 0x00002000 0x0000007c 0x00000000 a.out.__DWARF.__debug_line
  0x00000002 dwarf-pubnames [0x000000010000307c-0x00000001000030f3) rw- 0x0000207c 0x00000077 0x00000000 a.out.__DWARF.__debug_pubnames
  0x00000003 dwarf-pubtypes [0x00000001000030f3-0x0000000100003131) rw- 0x000020f3 0x0000003e 0x00000000 a.out.__DWARF.__debug_pubtypes
  0x00000004 dwarf-aranges [0x0000000100003131-0x0000000100003181) rw- 0x00002131 0x00000050 0x00000000 a.out.__DWARF.__debug_aranges
  0x00000005 dwarf-info [0x0000000100003181-0x0000000100003288) rw- 0x00002181 0x00000107 0x00000000 a.out.__DWARF.__debug_info
  0x00000006 dwarf-abbrev [0x0000000100003288-0x0000000100003320) rw- 0x00002288 0x00000098 0x00000000 a.out.__DWARF.__debug_abbrev
  0x00000007 dwarf-str [0x0000000100003320-0x00000001000033fd) rw- 0x00002320 0x000000dd 0x00000000 a.out.__DWARF.__debug_str
  0x00000008 apple-names [0x00000001000033fd-0x00000001000034a9) rw- 0x000023fd 0x000000ac 0x00000000 a.out.__DWARF.__apple_names
  0x00000009 apple-namespaces [0x00000001000034a9-0x00000001000034cd) rw- 0x000024a9 0x00000024 0x00000000 a.out.__DWARF.__apple_namespac
  0x0000000a apple-types [0x00000001000034cd-0x0000000100003585) rw- 0x000024cd 0x000000b8 0x00000000 a.out.__DWARF.__apple_types
  0x0000000b apple-objc [0x0000000100003585-0x00000001000035a9) rw- 0x00002585 0x00000024 0x00000000 a.out.__DWARF.__apple_objc
(lldb)

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.

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).

Greg Clayton

3

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!