[lldb-dev] getting filename/line #
Randy Heiland via lldb-dev
lldb-dev at lists.llvm.org
Thu Jun 21 08:41:32 PDT 2018
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!
On Thu, Jun 21, 2018 at 11:34 AM, Greg Clayton <clayborg at gmail.com> wrote:
> 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
>
> > On Jun 21, 2018, at 8:18 AM, Randy Heiland via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >
> > 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.dylib`pthread_kill +
> 90
> > frame #2: 0x00007fffc4c09420 libsystem_c.dylib`abort + 129
> > frame #3: 0x00007fffc4cf8fe7 libsystem_malloc.dylib`free + 530
> > frame #4: 0x0000000100017138 pc-nb`BioFVM::
> Microenvironment::compute_gradient_vector(int) + 472
> > frame #5: 0x00000001000174ca pc-nb`BioFVM::
> Microenvironment::gradient_vector(int) + 42
> > frame #6: 0x0000000100021bc1 pc-nb`BioFVM::Basic_Agent::nearest_gradient(int)
> + 17
> > frame #7: 0x0000000100069ccc pc-nb`chemotaxis_function(PhysiCell::Cell*,
> PhysiCell::Phenotype&, double) + 364
> > frame #8: 0x0000000100054ecc pc-nb`PhysiCell::Cell::update_motility_vector(double)
> + 284
> > frame #9: 0x0000000100053262 pc-nb`PhysiCell::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-nb`PhysiCell::Cell_
> Container::update_all_cells(double, double, double, double) + 780
> > frame #16: 0x0000000100071a54 pc-nb`main + 2516
> > frame #17: 0x00000001001c5235 libdyld.dylib`start + 1
> > frame #18: 0x00000001001c5235 libdyld.dylib`start + 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
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180621/b563ac81/attachment-0001.html>
More information about the lldb-dev
mailing list