Thanks for the quick reply. unfortunately I am out of my work environment currently. So I can't check "Image lookup".
Yes, I am remotely debugging from command line lldb from Mac OS X (not with Xcode). It seems to be exploding those libraries in the path you mentioned. Below are commands that I was using. platform select remote-ios process connect connect://127.0.0.1:1234 The platform select remote-ios output is here : Platform: remote-ios Connected: no SDK Path: "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/8.1 (12B411)" SDK Roots: [ 0] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2" SDK Roots: [ 1] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.3" SDK Roots: [ 2] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/5.0" SDK Roots: [ 3] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/5.1" SDK Roots: [ 4] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/6.0" SDK Roots: [ 5] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/6.1" SDK Roots: [ 6] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/7.0" SDK Roots: [ 7] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/7.1" SDK Roots: [ 8] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/8.0" SDK Roots: [ 9] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/8.1 (12B411)" SDK Roots: [10] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/(null) ((null))" SDK Roots: [11] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/5.1 (9B176)" SDK Roots: [12] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/5.1.1 (9B206)" SDK Roots: [13] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/6.0 (10A403)" SDK Roots: [14] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/6.0 (10A5355d)" SDK Roots: [15] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/6.0.2 (10A551)" SDK Roots: [16] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/6.1.2 (10B146)" SDK Roots: [17] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/6.1.3 (10B329)" SDK Roots: [18] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/7.0 (11A4372q)" SDK Roots: [19] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/7.0 (11A465)" SDK Roots: [20] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/7.0.2 (11A501)" SDK Roots: [21] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/7.0.3 (11B511)" SDK Roots: [22] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/7.1.1 (11D201)" SDK Roots: [23] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/7.1.2 (11D257)" SDK Roots: [24] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/8.0 (12A365)" SDK Roots: [25] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/8.0 (12A4265u)" SDK Roots: [26] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/8.0 (12A4297e)" SDK Roots: [27] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/8.0 (12A4318c)" SDK Roots: [28] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/8.0 (12A4331d)" SDK Roots: [29] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/8.0 (12A4345d)" SDK Roots: [30] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/8.0.2 (12A405)" SDK Roots: [31] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/8.1.1 (12B436)" SDK Roots: [32] "/Users/xxxxxxxxx/Library/Developer/Xcode/iOS DeviceSupport/8.1.3 (12B466)" On Tue, Mar 17, 2015 at 1:09 PM, Greg Clayton <[email protected]> wrote: > When a shared library has internal symbols it doesn't want exposed, it can > mark then as internal. When these shared libraries get copied into the > dyld_shared_cache, all internal symbols are removed and all of their names > in the symbol table are replaced with a single string table entry that > points to "<redacted>". If you are debugging on a desktop remotely we > should be getting these symbols as the symbols are reconstructed when the > shared cache is exploded onto the host system. Xcode will download the > dyld_shared_cache and exploded it back into shared libraries into > "~/Library/Developer/Xcode/iOS DeviceSupport/*" where "*" is something like > "8.1 (XXXXXXX)" where XXXXXXX is the build number of the OS build. > > Did you hook your device up to Xcode and let it explode the shared cache? > Are you running this remotely on your desktop? If so what does the output > of "target list" show? Does it have the correct "remote-ios" as the > platform? > What does "image lookup -va 0x00000001905d89dc" show for the case you have > below? > > > On Mar 17, 2015, at 10:22 AM, Sridhar <[email protected]> wrote: > > > > Hi guys, > > > > I am new to lldb and I was trying to debug a "non debug" stack which I > don't have source code for it. In the call stack it shows something like > below. (It is arm64 iOS binary) > > > > frame #1: 0x00000001905d89dc AVLib`<redacted> + 80 > > > > I am not quite understand the reason behind showing the symbol name as > "redacted". They are objective C methods and dispatch blocks. C symbols are > actually fine. If I dissemble using IDA, it shows those symbol names > properly. Those symbols are from an external static lib and I loaded them > using add image command. When I search those symbols using "image lookup" > it shows all symbols from the static lib. So when I put a break point on > those symbols, it won't stop. Is there anyway to resolve the symbol names > and properly stop at breakpoint on these symbols ? > > > > I also see, incorrect calls symbols inside frames but when I step > through them they change to actual call frames. > > e.g the below call really won't go to VRTracePrint but some other symbol. > > 0x1905d8a18: orr w0, wzr, #0x3 > > 0x1905d8a1c: movz w3, #651 > > 0x1905d8a20: bl 0x190618244 ; symbol stub for: > VRTracePrint_ > > > > Thanks, > > Sri > > _______________________________________________ > > lldb-dev mailing list > > [email protected] > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
