s/quite likely there are binaries/quite likely there are libraries/ I should not drink and post.
On 5/14/15, Michael David Crawford <[email protected]> wrote: > The DWARF format is publicly documented. I expect there are some > tools that one can use to muck around with them, however those tools > may not come with Xcode. If there aren't actual executables quite > likely there are binaries. > > What you could - in principle - do, is to read each item in a DWARF > file, then in your own tool, replace the path, then create a new DWARF > file. > > But you'd have to do that in native code I expect. awk and sed are > great for text files, not so much for binaries. > > If you have a Mac that runs Classic around still, I think Quadrivio's > General Edit Lite is still available. The Lite version is free, but > doesn't know about any specific format. The paid version enables you > to write your own plug-ins, that enable General Edit to directly edit > the binary of any format you know about. > > There's lots of binary editors, but I've never found one that I liked > quite as much as General Edit Lite. > > On 5/13/15, [email protected] <[email protected]> wrote: >> The setting is actually a list of duples (do "settings list >> target.source-map" for more info.) So you can set as many mappings as >> you >> need to. >> >> You can set the mappings in ~/.lldbinit and Xcode will pick them up in >> all >> debugging sessions. >> >> It would not be safe to awk/sed the DWARF. Unless the two paths are >> exactly >> the same length, you will most likely mess up the string table and make >> the >> debug info unusable. >> >> Jim >> >> >> >>> On May 13, 2015, at 5:04 PM, Eric Wing <[email protected]> wrote: >>> >>> On 5/13/15, [email protected] <[email protected]> wrote: >>>> When you build a library, the location of the source files is written >>>> into >>>> the debug information which is stored in the dSYM. When you are in the >>>> debugger and stop in some code from that library, lldb uses the debug >>>> info >>>> to figure out where you have stopped, and load the source for that >>>> location. >>>> The debug information tells it the location on the build machine, but >>>> there's nothing to tell us where the sources are on the debugging >>>> machine. >>>> You have to do that by hand. >>>> >>>> The way to do that in lldb is to set the "target.source-map" setting. >>>> So >>>> for instance, if on the builder your project was in >>>> /Volumes/Builder/Sources, and on the users machine the sources are in >>>> /Volumes/TheirDisk/Sources, you would say: >>>> >>>> (lldb) settings set target.source-map /Volumes/Builder/Sources >>>> /Volumes/TheirDisk/Sources >>>> >>>> Then lldb will take any source file that claims to be under the >>>> original >>>> hierarchy, and look for it under the new hierarchy instead. >>>> >>>> If you don't know the original build directory, just do: >>>> >>>> (lldb) image lookup -vn <SomeFunctionInTheLibrary> >>>> >>>> and one of the output lines will be the CompileUnit. That will show >>>> the >>>> path to the source file that was in the DWARF. This generally isn't at >>>> the >>>> top level of the build hierarchy, so you'll need to go back a couple of >>>> directories. You can generally tell what the common base is from >>>> looking >>>> at >>>> the sources you've downloaded. >>>> >>>> Jim >>>> >>> >>> That is very useful information. Thank you! >>> >>> >>> A couple of follow up questions. >>> >>> - I actually have a dozen or so libraries. Is it possible to set >>> multiple maps at the same time if they don't share a common root? >>> >>> - I noticed that Xcode is not remembering what I set between runs. The >>> lldb up-arrow history helps, but is there a way to make this a little >>> more persistent? >>> >>> - Or maybe, is there a way I could use something like awk/sed/Perl to >>> rewrite the paths for the user's copies of the .dSYM and .a files so >>> re-entering in lldb isn't required every single time? >>> >>> Thanks, >>> Eric >>> -- >>> Beginning iPhone Games Development >>> http://playcontrol.net/iphonegamebook/ >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Xcode-users mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/xcode-users/mdcrawford%40gmail.com >> >> This email sent to [email protected] > > > -- > Michael David Crawford, Consulting Software Engineer > [email protected] > http://www.warplife.com/mdc/ > > Available for Software Development in the Portland, Oregon Metropolitan > Area. > -- Michael David Crawford, Consulting Software Engineer [email protected] http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
