debugserver has a memory use problem when a process has many (1000+) binaries loaded in it. lldb sends the jGetLoadedDynamicLibrariesInfos packet to get a JSON description of those binaries -- load address, filepath, mach-o header, mach-o load commands. This can result in such a large packet that it will temporarily cause debugserver's memory use to balloon up for the duration of the packet processes. I made a first crack at this problem a year ago ( https://reviews.llvm.org/D122848 and https://reviews.llvm.org/D122882 ) to reduce unnecessary copies while creating this response, but inevitably there will be more binaries and we'll be back here again.
This patch adds a new option to the jGetLoadedDynamicLibrariesInfos fetch-all-binaries packet to only report the mach-o load addresses and the filepaths -- to skip the mach-o header & load command scan and JSONification. The default behavior is unchanged.
In a future patch, I will change DynamicLoaderMacOS to request binaries in batches of maybe 300 per request. When it attaches to a new process, it will ask for the load addresses of the binaries, and get the full information in these batches. On notification of new binaries being loaded, it will already have the load addresses and can skip this first request.
As long as I was updating this code, I also removed support for our pre-iOS 10/macOS 10.12 way of querying binaries loaded in a process. We can't build debugserver with a deployment target that old any more; it is not testable.
This patch does have a regression on API/macosx/unregistered-macho/TestUnregisteredMacho.py that I wrote last summer; I have the patch generate JSON for a binary that it had an address for, but could not read the mach-o headers. This test case is specifically testing the address of something that is not a mach-o in memory and testing that nothin is returned. I need to revisit why I wrote this before I fix it by changing my patch or removing the test, but the reason for the test failure is obvious, it's a minor revision either way.
Why do we still want to add information about this dylib if the mach header isn't valid?