Re: Finding the use of a private API
Re: Finding the use of a private API
- Subject: Re: Finding the use of a private API
- From: Rick Mann <email@hidden>
- Date: Mon, 16 Mar 2015 19:33:11 -0700
> On Mar 16, 2015, at 19:21 , Greg Parker <email@hidden> wrote:
>
>
>> On Mar 16, 2015, at 4:47 PM, Rick Mann <email@hidden> wrote:
>>
>>> otool -t -V APP > /tmp/longFileOfDisassembly
>>>
>>> vi the file and look for _dsyrk_ instances, they should be in comments like ## symbol stub for _dsyrk_
>>>
>>> scan backwards to find what routine you’re in, should be a couple of screenfuls up at most.
>>>
>>> Obviously better using a debug version of the code :)
>>
>> I tried that. I get this:
>>
>> $ otool -tV MyApp | edit
>> otool(49911,0x7fff7f1cd300) malloc: *** error for object 0x6b2db0: pointer being freed was not allocated
>> *** set a breakpoint in malloc_error_break to debug
>
> Are your command-line tools out of date with respect to your installed Xcode? Try using `xcrun otool` and similar for the other command-line tools you run.
>
>
>> But it does generate a couple million lines of output before crashing. I can find only one reference:
>>
>> 00175308 f3c4e972 blx 0x5395f0 @ symbol stub for: _dsyrk_
>>
>> But nothing more. There doesn't seem to be any debug info (despite this being a debug build; the dSYM is separate, dunno how to incorporate that).
>
> That is a call site. Look upwards in the disassembly for the nearest preceding symbol. If you are lucky then that symbol will be a useful one. If you are unlucky then that symbol will be a red herring because the real symbol was stripped.
>
> otool will not read the matching dSYM file, but lldb will. Try this:
> 1. Place your app and your dSYM in the same directory
> 2. `xcrun dwarfdump -u /path/to/YourApp.app/YourApp` and `xcrun dwarfdump -u /path/to/YourApp.app.dSYM`. This will print UUIDs. Make sure the app and the dSYM match.
> 3. `xcrun lldb -arch arm64 /path/to/YourApp.app`. If your app is 32-bit then use `-arch armv7s` instead.
> 4. In lldb, `image list YourApp`. That should print YourApp's executable and its dSYM file.
> 5. In lldb, `x/i 0x00175308`. That should print the branch instruction that you found using otool.
> 6. In lldb, `image lookup -v -a 0x00175308`. That will print everything lldb knows about that address and the function it is in. If all has gone well then that will include function names, file names and line numbers, and any inlining involved.
Thanks, Greg, that's useful info. I ended up semi-manually searching various .o files generated, and we discovered that the Ceres build was looking for a different flag to avoid using dsyrk_. Once we got that building correctly, I was finally able to produce a binary that didn't try to link against it.
Sure would be nice if Xcode would just tell me where that symbol is referenced when app validation fails. ;-)
--
Rick Mann
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden