[lldb-dev] "redacted" symbol names

[Greg Clayton]

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 <sridhar124 at gmail.com> 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
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev