21

I've a framework with a dylib in my iOS app which was compiled on another machine. I checked out the sources on my machine and tried instructing lldb to map the source code path using:

settings set target.source-map /source/code/path/in/dylib/prefix /source/code/path/on/my/machine/prefix

To no avail, still seeing assembly.

Note #1: the dylib was compiled from C++ code in the same version of Xcode.

Note #2: I'm used nm -pa /path/to/dylib to determine whether file paths are embedded into the debug info, and they are, lldb doesn't play along for some reason.

Thanks

UPDATE

I've followed Jim Ingham's answer below and created a script that automates this, the script is available as a gist link in this article I wrote: https://medium.com/@maxraskin/background-1b4b6a9c65be

Max Raskin
  • 1,042
  • 1
  • 14
  • 26

1 Answers1

16

To debug code built on one machine but debugged on another you have to build a dSYM and have that available on the machine on which you are debugging. If you haven't done that, nothing is going to work.

Next thing to check is that lldb is picking up the dSYM. This page has some description of how this process works:

http://lldb.llvm.org/symbols.html

but if all else fails, you can use the add-dsym command to add it by hand.

If that still hasn't fixed your problem, then pick some symbol in your dylib, and do:

(lldb) image lookup -vn <SYMBOL_NAME>

or alternately find some address in the loaded dylib and do:

(lldb) image lookup -va <ADDRESS>

If lldb found the dSYM and the debug info is correct, one of the lines of output should be the entry for the "Compile Unit". That is what the debug info says the path to the source file is. The appropriate base of that path is what you should use in target.source-map. If you don't see that entry, then the debug information for that compilation unit is getting lost somehow.

If all those things look good and lldb still isn't seeing the source files, then you are likely hitting a bug, in which case please file a bug with http://bugreporter.apple.com.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
  • Thanks for the detailed reply, that worked, I was indeed missing the dSYM. I used `add-dsym` and pointed out the dSYM path, then I used `image lookup -vn ` to get a symbol source code path, and then changed the mapping using `settings set target.source-map /path/prefix/i/got/from/lookup /path/prefix/on/my/machine`. – Max Raskin Jan 25 '17 at 08:14
  • btw - for Debug builds of a dylib, is a dSYM required, or is the same data embedded within the dwarf file? – Max Raskin Jan 25 '17 at 08:31
  • 2
    On OS X, the compiler writes debug information into the .o files, and writes a "debug map" in the final binary image that tells lldb how to find the .o files and link up the dwarf in them. So if you are debugging in place, you don't need a dSYM. However, if you are debugging a binary after deleting the Intermediates folder, or on a machine that doesn't have that directory or has it in a different location, you need to make a dSYM and use the dSYM for debugging. – Jim Ingham Jan 25 '17 at 20:18
  • Not sure if this is the same issue, but when using flex, I'm not seeing association of the derived source when debugging. The path to the derived source is eg Project/Build/Intermediates/XCodeSnaz.build/Debug/XCodeSnaz.build/DerivedSources/lexer.yy.cpp The file is being found with 'image lookup -vn cFlexLexer' but no source code association. – Konchog Feb 13 '20 at 08:07
  • Updated link: https://lldb.llvm.org/use/symbols.html – user1763487 Jun 24 '20 at 08:31