Re: How to allow users of pre-built libraries step into code in the Xcode debugger?
Re: How to allow users of pre-built libraries step into code in the Xcode debugger?
- Subject: Re: How to allow users of pre-built libraries step into code in the Xcode debugger?
- From: Michael David Crawford <email@hidden>
- Date: Thu, 14 May 2015 00:59:27 -0700
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@hidden <email@hidden> 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@hidden> wrote:
>>
>> On 5/13/15, email@hidden <email@hidden> 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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
Michael David Crawford, Consulting Software Engineer
email@hidden
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden