llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.72k stars 11.88k forks source link

[Windows][LLDB][Ios] libobjc.A.dylib is being read from process memory. #94921

Open doraorak opened 4 months ago

doraorak commented 4 months ago

Latest llvm/lldb Host: Windows11 Remote: Iphone 14 pro max on ios 17.4 Protocol: gdb-remote process: Instagram

Issue: getting warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not find the on-disk shared cache for this device. This will likely reduce debugging performance. when attaching to a process.

Expectation: to statically provide this library so the warning doesn't show up.

reproduce steps:

  1. connect to the debugserver via gdb-remote
  2. attach to the process via pid
  3. warning shows up

notes: I am aware of fixes of this issue on macos but couldn't find anything about windows. Thanks in advance.

llvmbot commented 4 months ago

@llvm/issue-subscribers-lldb

Author: None (doraorak)

Latest llvm/lldb Host: Windows11 Remote: Iphone 14 pro max on ios 17.4 Protocol: gdb-remote process: Instagram Issue: getting warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not find the on-disk shared cache for this device. This will likely reduce debugging performance. when attaching to a process. Expectation: to statically provide this library so the warning doesn't show up. reproduce steps: 1. connect to the debugserver via gdb-remote 2. attach to the process via pid 3. warning shows up notes: I am aware of fixes of this issue on macos but couldn't find anything about windows. Thanks in advance.
jimingham commented 4 months ago

This is a general problem with remote debugging. The gdb-remote protocol is somewhat slow, so lldb works a lot better if it can read symbol information from a host-side copy of the remote binaries rather than having to read symbols from memory across the gdb-remote interface.

Currently, lldb doesn't know how to extract this information from a remote device. When you are using a macOS host to debug to iOS, Xcode & CoreDevice cooperate to copy the shared cache from the device, then turn it back into individual dylibs, and fix up some symbols, and put the result somewhere lldb knows to find it.

This isn't specific to debugging to an iOS device. If you are doing any kind of remote debugging, symbol reading will be much faster if you can get a copy of the major system libraries on the host side.

We could add a Platform::CopyRemoteBinaryImagesToHost API if we wanted lldb to get into the business of handling this but for given other clients might want the same information, so far this has been provided by external agents.