[lldb-dev] Is there a just-my-code like debugging mode for LLDB?

[Emre Kultursay via lldb-dev]

Thanks for all the feedback and ideas.

After Jim's comment about iOS performance, I decided to dig deeper to
figure out why it's much slower to attach on Android compared to iOS. I
identified an ipv6/ipv4 issue about adb and the simple fix (llvm.org/D79757)
brought warm cache attach time down from 23 seconds to ~9 seconds, and cold
cache attach time from 120 seconds down to 16-20 seconds!! These are much
better numbers, but based on the numbers from Jim, I should probably
continue hunting for more Android-specific issues.

One thing I want to try is "settings set
plugin.process.gdb-remote.use-libraries-svr4 true". I measure it takes
~600ms to read the list of shared libs without this flag, and it's done 3
times from startup until we hit the first-breakpoint (load all system
libraries at attach time; then load base.odex, then load user-lib.so). So,
I expect this to shave up to ~1.8 seconds. I don't have any numbers on this
yet (does anyone know how much improvement I can expect with this?)

About my "don't-load-system-modules" idea (that I mistakenly called
"my-code-only" which is apparently something different): Pavel's concerns
about not loading modules sounds serious, especially about impacting
stability, and I'd like to avoid causing trouble there. So, instead of
that, I will try Greg's idea of pre-caching libraries. I'll start with some
measurements. I'm working from top-of-tree (I'm trying to build LLDB with
libxml2 now).


On Wed, May 13, 2020 at 3:08 PM Greg Clayton <clayborg at gmail.com> wrote:

> One reason to not only load your libraries is backtraces will be truncated
> for any stack frames that go through the system libraries. These tend to be
> in the stack traces a lot as we deal with Android all the time at
> Facebook...
>
> Greg
>
> On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
> Hi lldb-dev,
>
> *TL;DR: *Has there been any efforts to introduce something like "Just My
> Code" debugging on LLDB? Debugging on Android would really benefit from
> this.
>
> *Details:*
>
> Native Android apps typically have a single .so file from the user, but
> load ~150 system libraries.
>
> When attaching LLDB remotely to an Android app, a significant amount of
> time is spent on loading modules for those system libraries, even with a
> warm LLDB cache that contains a copy of all these libraries.
>
> With a cold LLDB cache, things are much worse, because LLDB copies all
> those libraries from the device back to the host to populate its cache.
> While one might think this happens only once for a user, things are a bit
> worse for Android. There are just too many libraries to copy, making it
> very slow, there are new Android releases every year, and users typically
> use multiple devices (e.g., x86, x86_64 emulators, arm32, arm64 devices),
> and multiple hosts (work, home, laptop/desktop); thereby suffering from
> this issue more than necessary.
>
> If we can eliminate the latency of loading these modules, we can deliver a
> much faster debugging startup time. In essence, this can be considered as a
> form of Just My Code debugging.
>
> *Prototype and Experiments*
>
> I built a simple prototype that only loads a single user module, and
> totally avoids loading ~150 system modules. I ran it on my Windows host
> against an Android emulator to measure the end to end latency of "Connect +
> Attach + Resume + Hit 1st breakpoint immediately" .
>
>    - For warm LLDB cache:
>       - Without just-my-code: 23 seconds
>       - With just-my-code: 14 seconds
>    - For cold LLDB cache:
>       - Without just-my-code: 120 seconds
>       - With just-my-code: 16 seconds
>
>
> I want to solicit some feedback and gather thoughts around this idea. It
> would be great if there are any existing alternatives in LLDB to achieve my
> goal, but otherwise, I can implement this on LLDB and I'd appreciate it if
> anyone has any advice on how to implement such a feature.
>
> Thanks.
> -Emre
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200513/8e9b1b88/attachment.html>